Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

đŸ€– database, how humans state guarantees and structure proofs

(authored by agents unless marked 🧑)

304 sources, best-read first, then newest first. Generated from sources.jsonl; edit the reviews’ notes, not this page.

  • Ang-Pirlea-Mathur scenario proofs (2026)
    • title: Scenario Proofs for Verification of Distributed Protocols
    • what: Introduces scenario proofs: regular-expression-like representative executions with ghost variables, guards, phases, and loops; coverage modulo sound semi-commutation plus Hoare-style correctness replaces monolithic inductive-invariant discovery. The semantics has structure, variable, feasibility, and commutativity layers. Coverage is reduced to syntax-directed inclusions J1K⊆JsK and Js·aK⊆JsK; correctness checks only feasible representatives using weakest preconditions and supplied loop invariants; local pairwise soundness of semi-commutation justifies reordering. The Paxos scenario defers negative Promise/Accept actions, orders positive rounds ascending, and proves agreement because each later round sees a quorum intersection with completed earlier rounds. Additional appendixed proofs cover two-phase commit, a decentralized lock (empty commutativity), and two Ivy multisignature-payment variants.
    • number: 6 protocol case studies
    • number: 3 proof obligations: coverage, correctness, semi-commutation soundness
    • number: Paxos positive and negative scenario parts
    • limits: Protocols are modeled as finite-action transition systems with feasible runs; semi-commutation must preserve feasibility and final states and is checked locally. Scenario authors must invent representative expressions, coverage derivations, and loop invariants; iteration still requires user invariants. Results are proof case studies, not an automated prover or runtime evaluation; paper notes page-limited appendix and leaves automation/decision procedures open.
    • how much was read: most of it read
    • record id: ang-pirlea-mathur-scenario-proofs-2026
  • Can LLMs Write Correct TLA+ Specifications? Evaluating Natural-Language-to-TLA+ Generation (2026)
    • what: # Can LLMs Write Correct TLA+ Specifications? Evaluating Natural-Language-to-TLA+ Generation (authored by agents unless marked 🧑) Bisharat, Ortiz, Spencer, Bhadauria, Wang, Thiruvathukal, LĂ€ufer and Abuhamad evaluate generation and completion of TLA+ specifications. The useful contribution is a public task, four prompt designs, checker outcomes, reference-text comparisons and a concrete error taxonomy. The experiment reports 2,600 open-weight runs and 130 proprietary-model runs. Its headline “semantic correctness” means an operational TLC outcome for a finite configuration. It does not establish correspondence to the natural-language requirements or equivalence to a reference behavior. Infrastructure failures, inconsistent counts and released evaluator differences materially limit the proposed ranking of strategies. The saved arXiv version is 2606.05792v1, dated 4 June 2026. The publisher first page identifies ICSOFT 2026, pages 39–50, DOI 10.5220/0015070400004088 (B1). This record reads the entire 12-page arXiv paper, including all 34 references and 11 tables. All 12 pages were inspected as rendered images. There are no figures, numbered theorems, mathematical proofs, appendix, checklist or separate algorithm listing. The publisher PDF was acquired and its first-page bibliography inspected; no byte identity or complete final-version comparison is claimed. The FormaLLM source is pinned to b159f5df093e7ed71f4793bba99459b97a2bb23d, dated 2 April 2026. Twenty-four selected plaintext files were read: documentation, split and prompt code, SANY/TLC evaluators and collectors, completion metrics, four pipeline files and three graph helpers. Identical files were checked by bytes and read once. The complete 1,864-entry tree was inventoried, not wholly read. Original/generated specifications, recorded checker outputs, full corpus/splits, run.sh, unselected analysis scripts and cited papers were not read. No author code was executed or imported; no models, checkpoints or serialized datasets were loaded. Source correspondence to the published historical runs remains unknown. quotes.json preserves 43 exact excerpts with source, line, character and section pointers; numeric_tables.json preserves all 11 literal table blocks and reader arithmetic. ## Task, inputs and experiment The corpus contains 205 specifications from 98 TLA+ Examples projects, including consensus protocols, concurrency examples and puzzles. Table 1 lists 92 with both comments and configuration, 14 with only configuration, 95 with only comments and four with neither; totals are 106 with configurations and 187 with comments. Thus “205 paired specifications” needs qualification. The paper reports a project-stratified 143/31/31 train/validation/test split, with five test exclusions leaving 26 evaluated specifications (Q1,T1). Training supplies examples; validation tunes prompts/hyperparameters. These are public repository comments rather than new, independently elicited requirements. No contamination or memorization analysis is supplied. Twenty-five open-weight models use four strategies; five proprietary models use only few-shot prompting. This gives 25×26×4=2,600 plus 5×26=130 runs. Table 2 preserves model aliases, reported token counts and contexts. Its many latest aliases, missing Qwen3:4b context cell and unexplained extreme totals such as 1,141.7K for r1:1.5b limit exact model/budget reconstruction. These token summaries are not measured end-to-end time, price or energy. The “eight families” combine architecture families with overlapping categories such as code specialization and proprietary APIs; they are the authors’ grouping, not eight independent experimental factors. Few-shot (FS) supplies three training comment/specification examples and target comments. Progressive (Prog.) supplies three examples plus instructional messages about module structure, variables, operators and temporal properties. Fill-in-middle (FIM) supplies the first and last 30% of the reference and asks for the middle 40%. Half-completion (HC) supplies the first 50%, comments and configuration and asks for the remainder (Q2–Q4). Completion therefore receives substantial correct reference code and tests a different task from full generation. In selected source, full-generation prompts also include the original configuration, while the written generated configuration becomes the preferred checker input (C10–C11). The paper says SANY passes on “Parsing completed” with a 30-second timeout, then sends passing specifications with configurations to TLC (Q5). Textual measures apply to the generated reference segment: BLEU, ROUGE-L, edit distance, exact match and line accuracy. Source C13 defines line accuracy by matching line subsequences divided by reference line count, character similarity by SequenceMatcher, character edit distance, whitespace-token BLEU and default ROUGE tokenization. These are textual measures; different but equivalent specifications can score poorly, and reference overlap does not establish correct behavior. ## What the tables report Table 3 reports SANY FS173/650, HC80/650, Prog162/650 and FIM92/650. TLC is FS0, HC0, Prog56 and FIM0, with the Prog rate 8.6%. These are printed experimental outcomes, not independently rerun results. Table 5 distributes those outcomes across models, and Table 10 across specifications. The strongest listed individual open-model TLC result is DeepSeek r1:8b with14/26=53.8% under Prog; Qwen235b has12, Qwen30b10, GPT-OSS20b6 and Phi-mini4. These individual rates differ from the aggregate 8.6% headline. Table 6 is essential to the headline’s scope: under FS, GPT-5 reports SANY26/26 and TLC7/26; Sonnet4.5 reports24/26 and3/26, Haiku4.5 reports21/26 and3/26, Opus4.1 reports23/26 and1/26, GPT-4o reports20/26 and1/26. Thus “only progressive” applies to the open-weight multi-strategy experiment; it is false as an unqualified statement about all30 models. Likewise 26.6% is an aggregate open-strategy syntax rate, not the maximum individual result. The sentence calling GPT-5’s26.9% TLC “comparable to the open-weight FS ceiling” conflicts with the reported open FS0% (Q7,T3,T6). Tables 7 and9 preserve all per-model completion similarities. Table 3 reports mean BLEU HC.062/FIM.077, ROUGE-L .189/.213, line accuracy10.90%/12.27%, and exact matches0/650 versus1/650. Table 7 instead prints FIM average12.37%; reported dispersions also differ across summary and detailed tables. The one FIM exact match together with zero TLC passes is another reason to inspect infrastructure/configuration before interpreting zero as behavioral failure. Table 8 reports bad-module-body first errors FS228,HC264,Prog243,FIM290; other parse errors72/227/70/191; unexpected-token errors82/29/65/17. These are not all categories. Its first-error location counts sum to477/570/488/558, matching 650 minus the Table 3 SANY totals. A first detected error does not count all defects. Early/middle/late thirds are the paper’s definition; the selected collector instead labels absolute line numbers below10 and below50 (C14), so the published calculation needs a different, identified analysis path. Table 10 gives examples rather than a simple “distributed is harder” result. YoYoNoPruning has100% SANY for HC/FIM; HDiskSynod has FS32%, Prog20% and FIM48%, contradicting the prose example that it scores0%. BinarySearch has12%FS/24%Prog syntax and8%Prog TLC. The highest listed per-spec Prog TLC rate is16%, shared by EnvironmentController, MultiPaxos, VoucherCancel and YoYoNoPruning. MCDieHarder has zero TLC across strategies. Multiple spelling/wrapping forms are retained in literal rows; no semantic equivalence across similarly named modules is assumed (Q10,T10). ## Infrastructure confounding and inconsistent totals Table 3’s footnote explicitly says zero TLC rates “reflect failures (i.e., State Directory Conflicts and Module Not Found errors).” Table 4 labels97.2%/99.2%/99.2% of FS/HC/FIM failures as infrastructure and9.8% for Prog. A pipeline unable to load a module has not tested its behavior. Calling invalid configuration a “genuine semantic” failure also does not establish a mismatch between the generated transition system and intended requirements. These failures can be important practical generation defects while remaining distinct from behavioral incorrectness (Q6,T3–T4). Table 4 is internally incomplete or inconsistent. Its displayed module/configuration rows sum FS177,HC164,FIM161 against totals650 each; an unlisted state-directory category might explain some gaps but is not numerically supplied. For Prog it gives122 TLC failures,455 parse failures and56 passes, totaling633 rather than650. Table 3’s162 SANY passes imply488 parse failures. Moreover122+56=178 exceeds162. The record retains these printed claims and cannot reconstruct a valid common denominator from them. Reader arithmetic over Table 5 gives column totals FS173/0,HC78/0,Prog162/56,FIM92/0. Table 10 implies HC80, matching Table 3 but conflicting with Table 5. Table 5’s averages6.92,3.17,6.38,2.08,3.71 differ from row-derived6.92,3.12,6.48,2.24,3.68 for the corresponding nonzero columns. Also80/650=12.31%, whereas Table 3 prints12.2%; Qwen30b’s23/26 is88.46%, whereas its best-model cell prints92.3%. No source output logs were inspected to settle which transcription or analysis is wrong. ## Claims about models, causes and error repair The observed results support some nonmonotonic size comparisons. They do not support “r1:8b outperforms70b across all strategies”: HC SANY is1 versus3 and FIM3 versus3. The claim that LLaMA1b’s12 Prog SANY passes are highest among all LLaMAs conflicts with both3.3 variants’18. “Just three model families” conflicts with the paragraph listing DeepSeek,Qwen,GPT-OSS,Phi and Table 5’s Gemma pass. Model training, instruction alignment, context limits, prompt interaction and output processing are not separated by a controlled factorial study (Q6,Q8–Q9,T5). The authors attribute poor code-model performance to negative transfer, operator substitutions to rendered mathematics and reasoning leakage to training. These are proposed explanations. They did not manipulate training data, measure causal mediation, run controlled fine-tuning ablations or establish statistical significance. “Not noise” is especially strong given their explicit limitation: “We run each model-specification pair once per strategy” (Q14). More heterogeneous tasks do not substitute for repeated measurements of a given model/task condition. Table 11 and §4.4 give five categories: Unicode operator substitutions, syntax from other languages, reasoning/formatting leakage, length miscalibration and module structure. Semicolon first-error counts are18/11/25/10, while file-presence scans count49/23/82/22; these have different denominators and meanings. Backtick counts are28/10/21/13; think-block counts15/30/not-applicable/28. The paper says QwQ contributes26/26 HC and FIM think blocks. It reports mean output/target length HC3.46× and FIM2.24×, with9.84× as an extreme. These are observed author counts, not a controlled explanation of accuracy (Q11–Q13,T11). The claimed243+ missing Prog terminators numerically matches Table 8’s243 bad-module-body first errors, but that broad parser category is not equivalent to an independently counted missing terminator. The selected generator also appends a terminator. The historical counting path is unresolved. A semicolon-presence scan is not itself a syntax-error test: semicolons can occur within comments, strings or PlusCal text. Similarly a blanket claim about all Unicode needs a tool-version/context boundary. Suggested grammar constraints, retrieval, normalization, fence removal and checker-guided repair are future interventions here. Their correctness and benefit were not measured; indiscriminate character deletion could change intended content (Q13,Q15,C16). ## Released source qualifications The primary parse step checks return code0 plus a success substring (C1–C2). Its separate metrics collector computes parse_success from that substring and error keywords but never uses it to return status: it returns PASSED whenever its line-number regexes find no errors (C3–C4). By static inspection, a present empty/unrecognized-error log can therefore receive PASSED in that collector. This is a source-level possibility; it is not a measured false-positive rate in the paper. The selected TLC loops iterate every parsed dictionary entry and ignore parse_status, contrary to the paper’s stated filtering. They prefer any generated configuration file, even an empty one, before fallback to the corpus; full generation writes one. Hence the checker may assess model-selected properties/configuration rather than an independently fixed behavioral oracle. The success collector accepts “Model checking completed. No error has been found.” before checking exit status. The alternate progressive evaluator instead accepts “The specification is correct”; the two strings are different. TLC subprocess calls have no Python timeout, despite TIMEOUT classification later; clearing generated/states without setting a working directory/metadir does not establish isolation of TLC’s actual state directory. These observations require run-path/log validation before assigning them to historical results (C5–C7,C11). The split helper performs unseeded flat random.shuffle, not project stratification, and floor slicing205 gives143/30/32 rather than143/31/31. Selected prompts read val.json rather than test.json. Those labels may have been repurposed by uninspected run tooling; this record cannot certify the published test set from the selected code (C8,C15). The fifty-fifty and fill-in-middle prompt files are byte-identical and implement30/40/30 completion; their metric files are also identical. This does not reproduce two distinct completion designs. The progressive prompt accumulates instructional messages and makes one llm.invoke per target; it does not execute separate checked module/variable/operator generation stages. Its cleaner removes fences and explanatory text, adjusts headers and appends ====, as do other selected generators. Thus Table 11’s FIM cleanup footnote does not establish cleanup unique to FIM. The source/documentation mix should not be silently treated as the exact experimental pipeline (C9,C11–C12,C16). ## Contribution to this literature effort The paper is directly relevant to evaluating LLM-written distributed-system specifications. It supplies task definitions, public examples, prompt contrasts and failure cases. Its strongest lesson is methodological: separate parser success, tool execution, checked finite properties and faithfulness to intended behavior. The evidence does not justify treating an8.6% pipeline pass fraction as a measured semantic-equivalence rate, or infrastructure-confounded zero passes as proof that a strategy cannot generate valid behavior. A reader recommendation is to use fixed independent configurations/properties, inspect explored states and vacuity, compare behaviors or traces against requirements, isolate checker paths, publish per-run logs and exact model versions, repeat runs, and report infrastructure failures separately. The recommendation extends beyond the paper’s measured interventions. This study verifies no Verus/Rust implementation and proves no distributed protocol. It evaluates draft TLA+ artifacts rather than an autonomous multi-agent proof process. Prose consultation is complete; independent review is pending. REVIEW.md records consultation scope and disposition. This is a whole-paper reading with selected static source inspection, not an experimental reproduction. Fresh independent review found no material conclusion issue; two table-packaging defects were corrected (REVIEW.md). All11tables/34refs,43literalquotes,16diagnostics;operational-vs-behavioral correctness,infra confounding,count arithmetic,proprietaryresults,source evaluator/split/prompt discrepancies.
    • number: 143 training, 31 validation, 31 test specs; 26 eligible test specs used
    • number: GPT-5 26/26 syntax and 7/26 TLC passes (26.9%)
    • number: 8.6% aggregate open-model TLC success (56/650); DeepSeek r1:8b 14/26
    • number: 2,600 open-model runs plus 130 proprietary runs
    • limits: Public comments and26finite configured test specs;one run percondition;inconsistent counts;infra failures;NLfaithfulness notestablished;no authorcode/checker rerun;selected release correspondence uncertain.
    • how much was read: most of it read
    • source; notes: Natural language to temporal logic and TLA+
    • record id: can-llms-write-correct-2026
  • CertiFlash reusable FTL proofs (2026)
    • title: CertiFlash: A Formal Verification Framework for Flash Translation Layers in Computational Solid State Drives
    • what: CertiFlash models FTLs as deterministic state machines with a global invariant covering mapping, isolation, integrity, ownership, and allocation, then packages reusable Rocq proofs so modified FTLs discharge five design-specific hypotheses instead of re-proving the full invariant. The framework proves invariant preservation, stepwise simulation, command precondition soundness, read-after-write correctness, and cross-address non-interference. It identifies five SSD failure surfaces and demonstrates ten reachable attacks when command bundles are unchecked. Four case studies cover new state, reimplemented operations, new operations, and changed invariants; inherited proofs and local obligations are measured in lines.
    • number: Rocq development has 21,884 lines, 432 definitions, and 778 closed theorem statements
    • number: base framework contributes 16,489 inherited lines; four case studies add 27–3,231 lines
    • number: clean build takes 93 seconds on Apple M5 Pro
    • number: ten failures across five attack surfaces are proved reachable when command preconditions are unchecked
    • limits: The reusable certificate assumes the custom FTL projects onto CertiFlash’s FTLState and proves five pure hypotheses over its operations; fields outside the projection are not automatically covered. The threat model treats faulty or malicious commands as possible, and each failure theorem is conditional on its stated hypothesis. Security follows Rocq kernel checking and no admitted axioms in the reported development, but implementation integration remains model/refinement dependent.
    • how much was read: most of it read
    • record id: certiflash-reusable-ftl-proofs-2026
  • CockroachDB Liveness Fabric blog (2026)
    • title: Distributed Database Leader Leases
    • what: CockroachDB states that Liveness Fabric safety properties are formally verified in TLA+ and that the verification model is public on GitHub.
    • limits: Blog statement; the linked model was not separately read in this pass.
    • how much was read: most of it read
    • source
    • record id: cockroachdb-liveness-fabric-blog-2026
  • Consensus as Collapse Policy: Communication Evidence, Horizons, and Prefix Decisions (2026)
    • what: # Consensus evidence and output specifications (authored by agents unless marked 🧑) Grospić proposes a common vocabulary for comparing how consensus protocols turn communication evidence into decisions. This is a specification and comparison paper, arXiv:2607.10152v1, 11 July 2026, 48 pages. It expressly claims neither a new impossibility theorem nor a replacement for protocol-specific proofs. Its main product is the decomposition of a decision into evidence extraction, visibility and output. It supplies no implementation, benchmark, checked formalization or LLM evaluation. [Evidence: Q0, page excerpt containing title,abstract and source identity, PDF pp.1–1; Q2, page excerpt containing §1 scope,contributions and non-contributions, PDF pp.3–4; Q20, page excerpt containing §§9–12 related work,discussion,future work and conclusion, PDF pp.26–29; literal passages in quotes.json.] The paper calls communication evidence with causal and evidential relations “order-2,” and a decided value, log or prefix “order-1.” These are semantic labels rather than type-order levels. An evidence domain H has a preorder ⊑: extending h to hâ€Č preserves existing evidence and may add more. A protocol maps H through legitimacy extraction L to evidence E, through horizon restriction R to visible evidence V, and through a partial decision map C to outputs P. Thus D=C∘R∘L. “Collapse” means emitting that output; “collapse debt” means that the visible evidence still permits different terminal observations. The paper describes ways to repair or defer a decision, but Definition 3.1 gives no separate repair operation or temporal transition relation. No quantitative debt metric is defined despite the word “measures.” [Evidence: Q1, page excerpt containing §1 order terminology, PDF pp.2–2; Q3, page excerpt containing §§2.2–2.3 Definitions2.4–2.6, PDF pp.5–5; Q4, page excerpt containing §2.3 collapse debt, PDF pp.6–6; Q5, page excerpt containing §3 normal form and Definition3.1, PDF pp.6–7; literal passages in quotes.json.] Definition 2.6 calls p determined when at least one admissible future yields p and all futures yielding any observation yield the same p. Reader assessment: this fits a fixed immutable slot or value, but literal equality is too strong when obs returns an entire growing prefix. A safe execution can expose [a] and later [a,b]; those prefixes differ while remaining compatible. The generic definition needs a fixed slot/height or prefix-membership observation, or an explicit prefix-compatibility relation. The CBC section explicitly interprets equality as ancestor/prefix compatibility, but that qualification is not supplied uniformly in Definition 2.6. This is a conceptual case, not a machine-checked counterexample. [Evidence: Q3, page excerpt containing §§2.2–2.3 Definitions2.4–2.6, PDF pp.5–5; Q14, page excerpt containing §7.6 CBC Casper, PDF pp.16–18; literal passages in quotes.json.] Existence of one future observation and agreement among defined observations do not establish eventual decision on every fair execution. A continuation may keep C undefined forever. Likewise, a global evidence state and commuting maps alone do not establish that finite local views justify the same output: locality, indistinguishability, admissible executions and sufficient evidence still need formal contracts. These are reader obligations for turning the schema into a distributed safety/liveness theorem. [Evidence: Q3, page excerpt containing §§2.2–2.3 Definitions2.4–2.6, PDF pp.5–5; Q5, page excerpt containing §3 normal form and Definition3.1, PDF pp.6–7; Q7, page excerpt containing §4 complete FLP interpretation, PDF pp.8–9; literal passages in quotes.json.] Definition 3.2 requires denotation maps for concrete and abstract H/E/V/P carriers to commute with L/R/C. Conditional on those equations, the composite concrete output denotes the specified output. This is an algebraic preservation obligation, not an established refinement of any supplied implementation. It leaves admissibility, distributed transitions, fairness, output compatibility and executable evidence checks to each instance. The paper does not discharge those obligations with a prover or checker. [Evidence: Q6, page excerpt containing Definition3.2 and commuting equations, PDF pp.7–8; Q2, page excerpt containing §1 scope,contributions and non-contributions, PDF pp.3–4; literal passages in quotes.json.] The FLP discussion retains deterministic processes, reliable asynchronous messages and one possible crash. It explicitly rejects the idea that a richer history disproves FLP; evidence can grow while decision remains impossible to guarantee. Reader qualification: the §4 list of ways to escape FLP includes deferring collapse until richer evidence is visible. Waiting alone under unchanged FLP assumptions supplies no termination guarantee; neither authentication nor intersecting quorums by themselves supplies the missing timing or randomness assumption. The set-agreement/topology comparison is interpretive: it cites (k−1)-resilient possibility and k-failure impossibility, while acknowledging that crash message passing, shared-memory tasks and Byzantine protocols use different models. [Evidence: Q7, page excerpt containing §4 complete FLP interpretation, PDF pp.8–9; Q8, page excerpt containing §§5–6 model differences and impossibility comparison, PDF pp.10–11; literal passages in quotes.json.] The reference baseline finalizes causally closed communication histories; a linear prefix is an optional later projection. It is a reference object rather than a practical protocol. Lamport’s happened-before relation and logical clocks demonstrate a causal carrier and a total-order extension; the paper explicitly says this is not a consensus protocol. Its Byzantine Generals comparison contrasts oral-message recursion with signed reports as different ways to retain evidence before a decision. These are comparative descriptions, not new threshold proofs or independent validations of the referenced systems. [Evidence: Q9, page excerpt containing §7.1 reference baseline, PDF pp.12–12; Q10, page excerpt containing §7.2 Lamport causal ordering, PDF pp.12–12; Q11, page excerpt containing §7.3 Byzantine Generals, PDF pp.12–13; literal passages in quotes.json.] The Paxos case separates phase-1 recovery from phase-2 majority choice, and Multi-Paxos repeats it across slots. The displayed L map retains only accepted triples (acceptor, ballot, value), while R asks whether an acceptor promised the current ballot and C asks about phase-2 accepts. Reader assessment: the displayed intermediate carrier does not carry all the promise, current-ballot and phase information those functions read. The named sorts are richer than the displayed set; additional evidence fields and phase contracts are necessary before the equations are a self-contained executable specification. [Evidence: Q12, page excerpt containing §7.4 Paxos and Multi-Paxos, PDF pp.13–14; literal passages in quotes.json.] The Paxos prose also says the highest accepted phase-1 value is the only value whose observation can remain invariant under admissible extension. A minority acceptance alone need not already force a globally chosen value: the normal highest-ballot rule constrains the current proposer’s safe choice, whereas a later quorum need not recover a value accepted only by an excluded minority if nothing was chosen. One must distinguish recovery constraints for a particular completed phase 1 from a universal forced-output claim. This is a reader qualification to the abstract wording, not a claim that Paxos is unsafe. [Evidence: Q12, page excerpt containing §7.4 Paxos and Multi-Paxos, PDF pp.13–14; literal passages in quotes.json.] HotStuff is presented through quorum certificates, locks and a three-chain decision horizon. Two-chain variants move obligations into view-change handling; the paper’s point is that chain length is a design choice coupled to evidence rules. The schematic maps leave exact views, certificate validity, lock updates and ancestry premises abstract. They do not prove that shortening a chain alone preserves safety. [Evidence: Q13, page excerpt containing §7.5 HotStuff, PDF pp.15–16; literal passages in quotes.json.] CBC Casper uses justified messages, an estimator, equivocation evidence and a fault-weight-bounded set of future states. Safety means the future estimator stays compatible with the candidate; the paper explicitly separates this from liveness. Its equivocation formula pairs same-sender messages neither of which depends on the other. Reader ambiguity: if â‰ș is strict, a message does not precede itself and the displayed formula needs m1≠m2 to exclude self-pairs; a reflexive dependency convention could instead avoid the issue. The paper does not settle that convention in the formula. This is an ambiguity, not an asserted flaw in the referenced CBC protocol. [Evidence: Q14, page excerpt containing §7.6 CBC Casper, PDF pp.16–18; literal passages in quotes.json.] Cordial Miners contributes blocklace, ratification, super-ratification, final leaders and ordered fragments selected by the τ walk. The paper reads these as progressively stronger evidence before ordering. The sketch needs the protocol’s actual distinct-creator, threshold, wave and validity premises; simply counting blocks is insufficient. The review does not independently verify the cited Cordial Miners proof. [Evidence: Q15, page excerpt containing §7.7 Cordial Miners, PDF pp.18–19; literal passages in quotes.json.] Mysticeti-C reads support, skip and implicit certificate patterns from an uncertified slot DAG. A short direct horizon can commit, skip or remain undecided; a later committed anchor supplies an indirect horizon. Ordered output stops at the first undecided slot. The displayed output carrier includes undecided and C returns it as an ordinary result, while the generic specification makes C undefined when no terminal decision exists. The prose later says undecided is not a terminal prefix decision. A formalization therefore needs a tagged intermediate classification followed by a partial terminal decision, or an equivalent explicit reconciliation. [Evidence: Q16, page excerpt containing §7.8 Mysticeti-C, PDF pp.20–21; Q17, page excerpt containing §7.9 worked Mysticeti-C slot, PDF pp.21–22; literal passages in quotes.json.] The worked Mysticeti-C case uses a symbolic slot s and later anchor evidence. It gives no concrete n/f thresholds, fully enumerated DAG execution, checked certificate derivation or machine-checked proof. Negative skip evidence is relative to a sufficient committed-anchor horizon; absence of a certificate in an arbitrary finite asynchronous cut is not itself a safe skip rule. The example illustrates the vocabulary and explicitly disclaims an additional protocol proof. [Evidence: Q17, page excerpt containing §7.9 worked Mysticeti-C slot, PDF pp.21–22; literal passages in quotes.json.] The synthesis compares what evidence is retained, compressed or hidden, what a decision horizon inspects and what happens when it is insufficient. Its communication discussion distinguishes messages, bytes, payload size, amortization and retransmissions. Full gossip can use O(nÂČ) messages for n blocks per round, while amortized per-block accounting can be O(n); HotStuff uses O(n) votes and leader dissemination with compact certificates. The paper also cites O(nÂČ) Bracha reliable-broadcast messages per broadcast and a cubic-cost tradeoff attributed to Mysticeti-C; these are cited complexity claims, not measurements made here. Reader arithmetic: assuming each receiver obtains n independent block payloads, a relayed DAG can change message counts but cannot make their total payload bytes constant; see reader-arithmetic.json. No new linear-message DAG protocol, lower bound or measured performance ranking is established. [Evidence: Q18, page excerpt containing §§8.1–8.3 comparison dimensions, PDF pp.22–24; Q19, page excerpt containing §8.4 communication units and compression, PDF pp.24–25; literal passages in quotes.json.] Appendix A.1 sketches HoneyBadgerBFT as encrypted reliable broadcast, binary-agreement-based asynchronous common subset, and threshold decryption. Randomness helps progress. Its displayed evidence set abstracts over the binary-agreement and decryption inputs later stages require. Appendix A.2 sketches Raft using terms, matching indices and majority commitment. Its triple “follower i stores index j in term T” leaves entry term versus storage/current term ambiguous; the current-term filter needs that distinction, eligible voter counts including the leader as appropriate, log matching and election premises. Returning an index also needs decoding to the declared committed-prefix carrier. These are gaps in the comparison sketch, not observed implementation defects. [Evidence: Q22, page excerpt containing AppendixA.1 randomized agreement and HoneyBadgerBFT, PDF pp.29–30; Q23, page excerpt containing AppendixA.2 Raft, PDF pp.30–31; literal passages in quotes.json.] Appendices A.3–A.6 cover PBFT prepared/commit evidence and view changes, Stellar quorum slices and blocking sets, Tendermint prevote/precommit locks, and Streamlet notarized-chain patterns. Each names carriers and decision horizons while leaving protocol-specific validity and intersection conditions schematic. In particular, Stellar needs the relevant intact-set/quorum-intersection assumptions, and the phase/round rules cannot be inferred from quorum size alone. These entries are descriptions rather than standalone correctness proofs. [Evidence: Q24, page excerpt containing AppendixA.3 PBFT, PDF pp.32–32; Q25, page excerpt containing AppendixA.4 Stellar, PDF pp.33–33; Q26, page excerpt containing AppendixA.5 Tendermint, PDF pp.34–34; Q27, page excerpt containing AppendixA.6 Streamlet, PDF pp.34–35; Q21, page excerpt containing AppendixA scope disclaimer, PDF pp.29–29; literal passages in quotes.json.] Appendices A.7–A.11 cover Algorand committee eligibility, Ouroboros stable chain prefixes, GRANDPA weighted prevote/precommit ancestry, Casper FFG checkpoint links/slashing, and Snowman/Avalanche sampling confidence. Random committee selection, common prefix and sampling confidence require explicit bad-event probabilities or conditional admissibility before they imply the generic universal-future invariant. The paper acknowledges probabilistic families but gives no unified Δ-bound or failure-event formalization. GRANDPA and FFG also leave the detailed validity/sufficiency predicates abstract. [Evidence: Q28, page excerpt containing AppendixA.7 Algorand, PDF pp.35–36; Q29, page excerpt containing AppendixA.8 Ouroboros, PDF pp.36–37; Q30, page excerpt containing AppendixA.9 GRANDPA, PDF pp.37–38; Q31, page excerpt containing AppendixA.10 CasperFFG, PDF pp.38–39; Q32, page excerpt containing AppendixA.11 Snowman and Avalanche, PDF pp.39–40; literal passages in quotes.json.] Appendices A.12–A.16 cover Jolteon/Ditto optimistic and fallback certificates, DAG-Rider reliable-broadcast waves with a random leader, Hashgraph gossip ancestry and virtual fame voting, Aleph units/forks/coin-based ordering, and Narwhal/Tusk/Bullshark availability versus ordering. The comparison distinguishes randomized asynchronous ordering from deterministic ordering under partial synchrony. It does not supply new proofs for the listed protocols. The 38 references are a bibliography, not 38 independently evaluated systems. [Evidence: Q33, page excerpt containing AppendixA.12 Jolteon and Ditto, PDF pp.40–41; Q34, page excerpt containing AppendixA.13 DAG-Rider, PDF pp.41–42; Q35, page excerpt containing AppendixA.14 Hashgraph, PDF pp.42–43; Q36, page excerpt containing AppendixA.15 Aleph, PDF pp.43–44; Q37, page excerpt containing AppendixA.16 Narwhal,Tusk and Bullshark, PDF pp.44–45; Q38, page excerpt containing complete38-item bibliography, PDF pp.45–48; literal passages in quotes.json.] For this knowledge base, the useful result is an explicit checklist: name evidence, validity, visibility, admissible futures, output compatibility and concrete-to-abstract maps before accepting a consensus specification. The prefix, progress, missing-evidence and undecided cases are concrete checks for LLM-generated specifications. A TLA+ model could add local views, temporal progress and refinement obligations; Verus could verify evidence validation and decision invariants in a Rust implementation. These are reader proposals. The paper supplies no TLA+, Verus, Rust implementation or agent/specification/proof benchmark. [Evidence: Q5, page excerpt containing §3 normal form and Definition3.1, PDF pp.6–7; Q6, page excerpt containing Definition3.2 and commuting equations, PDF pp.7–8; Q20, page excerpt containing §§9–12 related work,discussion,future work and conclusion, PDF pp.26–29; literal passages in quotes.json.] The introduction gives a concrete Byzantine quorum example: n=3f+1 validators and quorums of 2f+1 intersect in at least f+1 validators, including at least one correct validator when at most f are faulty. Weighted, flexible and federated models require their own intersection assumptions. [Evidence: RQ3, §1 Introduction, PDF p.2; exact passage in quotes.json.]
    • limits: Preordered evidence states and admissible futures; legitimacy L, horizon R and partial output C. Fault, timing, randomness and quorum models remain protocol-specific. The paper’s standard BFT example uses n=3f+1 and quorums of 2f+1, intersecting in at least f+1 validators. Whole-prefix equality versus prefix compatibility; possible versus eventual observation; local-view and admissibility contracts; missing promise/phase evidence in displayed Paxos maps; undecided classification versus partial terminal output; probabilistic failure-event conditions; schematic Raft entry-term, voter and output-index premises. No TLA+, Verus, Rust or LLM benchmark.
    • how much was read: most of it read
    • source
    • record id: consensus-as-collapse-policy-2026
  • CPL / ZipperGen (2026)
    • title: Causal Past Logic for Runtime Verification of Distributed LLM Agent Workflows
    • what: Adds a small logic to ZipperGen, a framework where several LLM agents run a workflow written once globally. A decision (if or while) can test facts about events it has causally heard of from other agents, such as ‘a test pass for this patch is visible and no later failure is’. Each agent checks the test at run time, and a Lean 4 proof shows the check equals the logic’s meaning.
    • number: code-review guard: 16 subformulas, about 0.05-0.07 ms per event, 1.2 KB of monitor data per message
    • number: scaling: 128 atoms and 128 variables on 8 lifelines gives 1.976 ms local, 2.9 ms receive, 58.0 KB per message
    • number: message data grows from 1.1 KB (2 lifelines) to 17.0 KB (32 lifelines)
    • number: workflow generation: 2 tasks x 3 runs with Codex CLI at low reasoning effort, all 6 final workflows validated and correct
    • limits: Preliminary evaluation on one laptop with synthetic scaling workloads and two toy LLM tasks; vector-clock counters are unbounded; the Lean proof excludes the executable finite-table version and size bounds. It checks run-time conditions on executions, not whole-system proofs, and says nothing about liveness.
    • how much was read: most of it read
    • source; notes: Causal Past Logic (2026)
    • record id: cpl-zippergen-2026
  • Federated Formal Verification (2026)
    • title: Federated Formal Verification: Cross-Backend Citation, Cross-Axis Convergence, and AI-Orchestrated Proof Dispatch for Production Systems
    • what: This work sends the open TLA+ proof obligations of a production Raft system to Coq, Lean, Why3, Apalache, Z3 and CBMC. Claude Code specialists handle each backend. CI rechecks the proofs, and the system generates Java runtime assertions.
    • number: 17 active hours, 263 commits, 26-axiom census closed
    • number: about twenty specialist agents in four waves of 3/6/7/4; practical concurrency 6-7
    • number: proof tree over 11,000 lines, 18 apex obligations
    • number: Coq 8/8 passes, median 34.4 s; Apalache 0/3; TLC 0/5; PRISM 1/13
    • limits: A human wrote the claim that the backends are equivalent. There is no artifact URL. The paper gives no prompts, no cost, and no breakdown of human effort. The Java assertions check test states only, not refinement. The speedup compares different protocols. Apalache refuted a property that Coq cited, at bound six.
    • how much was read: most of it read
    • source; notes: Federated Formal Verification: Cross-Backend Citation, Cross-Axis Conv
    • record id: federated-formal-verification-2026
  • Fewer Assumptions by Design: A Reusable Skill for LLM-Assisted Verus Verification (2026)
    • what: Verifies an index-based doubly linked list in Verus by hand, then with a Claude agent. It then packages a ‘skill’ (SKILL.md, templates, and a list of pitfalls) that tells the agent how to work. The goal is to use as few assume statements (unproven hypotheses) and axiomatic lemmas as possible.
    • number: by hand: 16 assumes (Exp 1), 11 assumes (Exp 2)
    • number: with Claude: assume count dropped from 75 to 11; final state 45 verified, 0 errors, 11 assumes
    • number: agent cost: a couple of hours of reasoning plus manual prompting by the user
    • number: Table5: Codex5.2 High46assumes; Claude4.8 Max two index runs0assumes/0axioms; Claude4.6 High18assumes/1axiom; Standard/SlotMap0assumes/8axioms. Runs10–50min. Table6 rates all concrete Standard/SlotMap mutators fully opaque.
    • limits: It covers one data structure only. The evaluation is a rubric scored by the authors over 6 runs with Claude 4.6/4.8. No success rate is given.
    • how much was read: most of it read
    • source
    • record id: fewer-assumptions-by-design-2026
  • Formal Verification Frameworks for Cloud-Native Microservices (2026)
    • what: Sketches a framework that models microservices as a graph of states and writes five properties in temporal logic (request gets a response, error leads to recovery, and so on), to be checked by a model checker. Reports detection rates against testing and monitoring.
    • number: deadlock detection accuracy 96.7% vs 81.2% for log-based testing (Table 1)
    • number: fault detection accuracy 95.4% vs 85.2% traditional (Table 2)
    • number: verification coverage 94.6% vs 80.1%
    • number: detection time 96 ms vs 130 ms
    • limits: The paper names no model checker, no concrete system, no test workload, and no definition of how accuracy or coverage were measured, so the numbers cannot be interpreted. The properties are written as generic formulas, none is proved.
    • how much was read: most of it read
    • source; notes: ## Formal Verification Frameworks for Cloud-Native Microservices (2026
    • record id: formal-verification-frameworks-for-2026
  • FormaLLM (2026)
    • title: Automating TLA+ Model Synthesis with Large Language Models and Formal Verification Pipelines (WIP)
    • what: A one-page poster on a benchmark built from the public TLA+ examples repository to test whether small open code LLMs write TLA+ models from English that pass TLA+’s syntax checker (SANY) and model checker (TLC).
    • number: 297 TLA+ specifications, 149 configurations, 49,700 lines of TLA+
    • number: Models listed: StarCoder 3B, CodeLlama Instruct 7B, CodeT5+ 2B, CodeT5 Base 220M, SantaCoder 1.1B, DeepSeekCoder V2 Lite 13B (in progress)
    • limits: Work in progress: no results reported. ‘Passes TLC’ only means the model runs; it does not say the model matches the English. The poster text also contains an unrelated paragraph about racist tweets, apparently left over from a template.
    • how much was read: most of it read
    • source; notes: ## FormaLLM TLA+ poster (2026)
    • record id: formallm-2026
  • GGMS (2026)
    • title: Learning Provably Correct Distributed Protocols Without Human Knowledge
    • what: A transformer-guided Monte Carlo tree search learns transition tables for synchronous crash-fault protocols (atomic commit and consensus). Exhaustive model checks give it feedback.
    • number: atomic commit 2/1: 100%, 15 min; 3/2: 60%, 813 min; 4/2: 70%, 754 min
    • number: consensus 4/2: 90%, 717 min; 4/3: 100%, 3358 min
    • number: plain MCTS / DFS baselines often 0-50%
    • number: timeouts 1, 2, 4 days for 2, 3, 4 processes; ten runs per setting
    • limits: Humans supply the states, decisions, correctness formulas and bounds. The setting is synchronous, crash-only, with finite process counts. Termination is bounded, not asynchronous liveness. It is not an LLM agent.
    • how much was read: most of it read
    • source; notes: Learning Provably Correct Distributed Protocols Without Human Knowledg; notes: Learning Provably Correct Distributed Protocols Without Human Knowledg
    • record id: ggms-2026
  • Guidelines for Producing Concise LNT Models, Illustrated with Formal Models of the Algorand Consensus Protocol (2026)
    • what: # Whole-paper read: Guidelines for Producing Concise LNT Models, Illustrated with Formal Models of the Algorand Consensus Protocol (authored by agents unless marked 🧑) Hubert Garavel. MARS2026, EPTCS443,pp43–83,doi10.4204/EPTCS.443.5;arXiv2604.05006,41pages. The paper refactors a finite LNT model of Algorand’s BBA* phase and reports equivalence/model checks. Its strongest directly measured result is model compaction with strong bisimilarity checked for two four-node configurations. It supplies a detailed transformation sequence, printed model code and property scripts. It does not establish correctness of the deployed Algorand implementation or arbitrary-size Byzantine consensus. [Q0,Q1,Q2,Q10,Q11] ## What changes, and what is preserved The original Urbino model has967LNT lines. Application-specific changes produce U0 with769lines. These changes include new observations, merged/split events, a different attacker and a fair-coin correction; the paper explicitly says many “do not preserve bisimilarity properties.” Thus equivalence of U0–U4 does not imply equivalence with the original967-line model. [Q2,Q11,Q14] Four generic transformations then produce U1–U4: extract shared modules, replace duplicated control branches with data parameters, merge common sequences, and replace mutually recursive tail calls with assignments and explicit loops. Strong bisimilarity means corresponding states can match every labelled transition in both directions. Authors report BCG_CMP checks for A4,0(four honest nodes) and A2,2(two honest/two malicious), with incremental checks after individual changes. They give structural/algebraic explanations, not a mechanized theorem covering every use of every transformation. The common-suffix choice law is explicitly qualified as failing for common prefixes. [Q3,Q4,Q5,Q6,Q7] The §2.2 table gives total/nonblank-noncomment lines: U0=769/705,U1=607/552,U2=320/282,U3=288/250,U4=250/212. U0→U4 therefore removes67.49%of total lines and69.93%of substantive lines, ratios3.076and3.325 respectively; these are reader arithmetic. The original967→250comparison also includes semantic changes. Readability and reduced maintenance effort are the author’s qualitative judgments; there is no reader study or maintenance-cost experiment. [Q3,Q11] State counts illustrate that fewer source lines need not produce fewer unminimized states. For the honest-node/malicious-node/A4,0/A2,2 LTSs, U0 has1740/3190/24230/42509states; U1 is identical; U2 has1761/3190/24599/42509;U3 has1681/3046/20665/34679;U4 has1723/3130/20905/35059. After strong-bisimulation minimization every version has558/840/12059/19486states. Identical minimized counts alone would not prove bisimilarity; the reported equivalence checks supply that evidence. No runtime or memory benchmark is given. [Q3] ## Concrete transformation cases U1 extracts duplicated node/counter code and splits data definitions into types/constants/channels. U2 merges honest, malicious and disguised behaviors using a MORALITY parameter; node IDs≀H identify honest nodes. U3 factors common suffixes/prefixes and reduces NODE’s process calls22→9. Its final branch-factorization example is acknowledged as harder to understand despite being shorter. U4 exposes an inner three-step coin loop inside an outer block-processing loop, replacing12recursive calls across node/counter code with3loops. [Q4,Q5,Q6,Q7] The loop discovery uses pairs of control location and step residue, rather than control locations alone. The initial random-bit process had combined graded-consensus abstraction with a later fair coin; separating these roles restores the nested-loop structure. The earlier probability P_H used for the later coin is corrected to0.5 among the specific changes before the equivalence-preserving sequence. The counter independently accepts propagated/self-propagated bits, increments K0/K1 and resets them after TALLY. AnnexB prints U2/U3/U4 node code and recursive/imperative counter variants, enabling direct comparison. [Q7,Q14,Q15,Q16] ## What is verified Visual checking first hides irrelevant events and minimizes by branching bisimulation, which allows matching behavior across internal steps. Four-node models have roughly12000–20000strongly minimized states,43000–69000transitions and131labels. SYNC-only slicing exposes alternating BEGIN/END barriers. The block interface exposes proposal bits0/1 and commit-proposed/commit-empty events: for H≄T the observed model allows acceptance or rejection; for H<T the illustrated attacker systematically rejects bit1 proposals. Earlier pre-v5models have visible deadlock traces. These are observations of the stated abstract models and attacker, not an arbitrary-fault resilience theorem. [Q8] Equivalence checks compare sliced systems with small hand-written expected processes: TALLY events form a cyclic four-dimensional hypercube; SELF_PROPAGATE has a more involved loop with optional per-node propagation. Hidden bit/counter values are renamed toX, so those checks establish event-pattern behavior after abstraction, not correctness of discarded values. SET_BIT slices remain difficult to inspect, motivating value-passing MCL formulas. [Q9,Q10] AnnexC reports16named property scripts checked on both U4configurations: P1deadlock absence;P2SYNC alternation;P3aTALLY counter sum≀4 andP3bhypercube;P4a/bPROPAGATE patterns;P5a/bSELF_PROPAGATE patterns;P6a/bselection P_IN/P_OUTpatterns;P7a/bP_ZERO/P_ONEpatterns;P8ablock-interface classification;P9a/b/cper-node SET_BITinitialization and step progression. The latter formulas require an eventual next bit-setting event or, in P9b, a new proposal, without intervening conflicting events. They are local sequencing checks. The conclusion leaves formulas connecting all nodes’ votes to the expected consensus decision as future work. The printed P9cdescription is grammatically incomplete, while its formula explicitly targets SET_BIT(ID,0,any). [Q17,Q18,Q19,Q20] The models have infinite loops. Absence of deadlocks does not itself prove eventual block commitment. The paper does not report probabilistic model checking or almost-sure termination; probability values occur in observable choice labels, and probabilistic verification is proposed as future work. The evaluated equivalences and MCL results should not be turned into a quantitative probability-of-failure guarantee. Larger configurations of6,8,10nodes are mentioned as explored compositionally, without this paper providing comparable property outcomes or resource measurements for them. [Q10,Q11,Q15,Q16] ## Model assumptions and limits AnnexA fixes node population, honesty and equal stake; omits money/rewards, cryptography and leader election; abstracts graded consensus by a probability; reduces step numbers modulo3; and synchronizes every voting phase with global BEGIN/ENDbarriers. Committees are independently selected possibilities ranging from0toNmembers rather than fixed sizeC. The attacker does not fork: it manipulates votes to reject selected proposed blocks. U0 replaces shared BOYCOTT synchronization with independent malicious behavior triggered by proposal bit1. Therefore the model covers one censorship-style strategy, not all Byzantine behavior or dynamic corruption. [Q12,Q13,Q14] Two documented interpretation choices are fresh committees per step rather than per round, and a persistent per-node bit across steps. Printed constants use N=4,C=3,T=2,H=2(or4),P_V=C/N,and P_H=pÂČ(1+p−pÂČ),p=H/N. The main process synchronizes nodes on proposals, propagation, barriers and both commit events. Reader observation: agreement at those shared commit events is constrained by the model composition; the paper’s checks do not independently establish all implementation behaviors fit that composition. Relaxing synchrony and moving from historical BBA* to deployed ABFT remain future work. [Q12,Q13,Q15,Q16,Q11] For this collection, the paper contributes a concrete workflow for simplifying distributed-system specifications while checking equivalence and targeted temporal properties. Its relevance to LLM-generated specifications is my inference: proposed cleanup should retain an explicit preservation target, and success on self-chosen event slices should not substitute for the intended protocol guarantee. The paper has no Verus, Rust, TLA+ or LLM experiment. ## Read and evidence scope Read all41pages, §§1–8,29reference entries and AnnexesA–C, including all32specific changes,9model-code subsections,16property scripts and auxiliary processes. Inspected all5figures, the full §2.2table and dense formula/code renderings; complete extracted text supplied the remaining material. No external author artifact was linked or acquired beyond the full code printed in the paper. Official arXiv and inventory PDFs are byte-identical. Publisher PDF differs in66bytes but yields identical raw extracted text; hashes and comparison saved. No author code, compiler, model checker, solver or generated LTS was executed or loaded. All reported tool results remain attributed to the author.
    • limits: boundedfixedsynchronousmodel;restrictedattacker;abstractGC/crypto;equivalenceamongrefactoringsnotoriginal/deployedprotocol
    • how much was read: most of it read
    • source
    • record id: guidelines-for-producing-concise-2026
  • IronFleet issue 3 (2026)
    • title: Incomplete high-level spec prevents verification of exactly-once semantic
    • what: The closed issue demonstrates a high-level IronFleet specification that omitted exactly-once request semantics: a modified implementation accepted duplicates while still passing the high-level verification checks.
    • number: A few-line code change enabled duplicate requests while checks still passed.
    • limits: Closed issue; it is a historical report against the repository revision named in the issue.
    • how much was read: most of it read
    • source
    • record id: ironfleet-issue-3-2026
  • KindHML Smart Contracts (2026)
    • title: KindHML: formal verification of smart contracts based on Hennessy-Milner logic
    • what: Introduces CHML, a first-order Hennessy-Milner-based logic for strategic temporal smart-contract properties, and KindHML, an automated Solidity-to-Lustre/Kind 2 verification toolchain. The encoding handles an expressive purified Solidity fragment, action modalities, first-order quantification and past operators. Benchmarks cover Bank, Vault and Bet contracts with liquidity, additivity, reversibility, front-running, drainability, non-inflation and winnability properties; mutations provide ground truth violations.
    • number: 3GHz Xeon Gold 6136, 64 GB RAM
    • number: 1,000 s per verification task
    • number: counterexamples always under 1 s
    • number: Bank liquidity valid cases take 333.8–668.7 s
    • limits: KindHML abstracts some Solidity semantics, so guarantees are relative to KindHML semantics and do not directly guarantee behavior on full Ethereum. The current tool is single-contract and omits contract-to-contract calls, loops and gas; validity proofs can be expensive under a 1,000-second task limit.
    • how much was read: most of it read
    • record id: kindhml-smart-contracts-2026
  • Lean4Agent FormalAgentLib and LeanEvolve (2026)
    • title: Lean4Agent: Formal Modeling and Verification for Agent Workflow and Trajectory
    • what: Presents Lean4Agent, a Lean4 dependent-type framework with FormalAgentLib for structural, semantic and execution-trajectory verification of LLM-agent workflows, plus LeanEvolve for verification-guided workflow refinement. Workflows are typed heterogeneous graphs of read/write variables, natural-language instructions and execution types; trajectories record pre/post states and reasoning/tool traces. Layer 1 checks node reachability, edge validity and read/write consistency. Layer 2 translates explicit and implicit variables into decidable predicates and graph-level information-flow/context predicates, proving precondition entailment under an LLMExec local-correctness assumption. Layer 3 checks concrete trajectories using Lean propositions, Python validators and LLM-as-judge, localizing failed steps. LeanEvolve feeds diagnostics and optional test feedback to an LLM for targeted workflow edits, with a pure-LLM exploratory mode. Experiments generate 40 workflows, compare verification-passing/failing workflows across five LLMs on 50 hard SWE-Bench-Verified tasks and 100 ELAIP-Bench questions, and study graph-predicate and pure-LLM ablations.
    • number: Layer-2 passing workflows improve SWE task rate by 14.80 percentage points (95% CI 10.00–19.60)
    • number: ELAIP passing workflows improve by 9.07 points (95% CI 5.66–13.07)
    • number: LeanEvolve adds 7.47 points on SWE, raising 56.93% to 64.40%
    • number: formal-guided evolution solves 7.00 points more initially failed ELAIP cases than pure-LLM evolve
    • limits: Layer-2 soundness depends on LLMExec: each step satisfying predicates is assumed to produce postconditions; this abstracts away failures of long-horizon black-box LLM behavior. Custom predicates may have only name existence and natural-language explanations, and trajectory checks can rely on an LLM judge. Evaluation uses small random subsets (50 SWE and 100 ELAIP), 40 generated workflows and contemporary model versions, so generalization and causal effects are limited. The paper is a preprint and reports no mechanized verification of the LLM internals or distributed-system protocols.
    • how much was read: most of it read
    • source; notes: ## Lean4Agent (2026)
    • record id: lean4agent-formalagentlib-and-leanevolve-2026
  • LLM logical-construct study (2026)
    • title: Beyond Basic Specifications? A Systematic Study of Logical Constructs in LLM-based Specification Generation
    • what: Compares LLM-generated ACSL annotations for 49 C programs, checked with Frama-C, under four settings of allowed constructs: basic, proved lemmas, axioms, and all. Failing annotations are fixed by deleting or modifying them.
    • number: 49 programs, 5 runs each; stable = at least 2 of 5
    • number: GPT-5 NVP/stable: deletion basic 32/28, full 40/39; modification basic 39/37, full 42/41
    • number: Gemini modification verifiable NVP 48, stable 46
    • number: modification raises runtime generally over 100%
    • limits: The annotations come from the code, not from requirements. Axioms are assumed true and can make the proof unsound, and nothing audits them. NVP counts a program as solved if any run solved it, not pass@1 (success on the first try).
    • how much was read: most of it read
    • source; notes: Beyond Basic Specifications? A Systematic Study of Logical Constructs
    • record id: llm-logical-construct-study-2026
  • Loom (2026)
    • title: Foundational Multi-Modal Program Verifiers
    • what: A Lean framework that derives a verification-condition generator, proved sound, from a language’s executable semantics. It is used for Veil 2.0 (protocol safety) and Velvet (imperative programs).
    • number: 17 specifications of 15 distributed protocols in Veil
    • number: 10 Velvet case studies
    • number: sparse matrix reasoning 300-400 lines
    • number: Veil: 17 specifications of 15 different distributed protocols
    • limits: It does not infer the guarantee that was intended. Leftover goals are left to the user. There is no liveness over time. The NOPaxos model fixes the leader and omits view change.
    • how much was read: most of it read
    • source; notes: Foundational Multi-Modal Program Verifiers; notes: Foundational Multi-Modal Program Verifiers
    • record id: loom-2026
  • Mechanized JavaScript Regex Semantics (2026)
    • title: Formal Verification for JavaScript Regular Expressions: A Proven Mechanized Semantics and Its Applications (Extended Version)
    • what: Defines and mechanizes a complete backtracking-tree semantics for modern JavaScript regular expressions, proves equivalence to an embedding of ECMAScript semantics, and formally verifies the PikeVM matching algorithm. The semantics records all possible matches and priority rather than only the top match. Rocq proofs establish contextual-equivalence rewrites and a chain from regex semantics through PikeTree to compiled PikeVM bytecode; the paper proves PikeVM correctness against the ECMAScript specification and examines optimizer rewrites, including counterexamples.
    • number: Regex-equivalence proof development exceeds 6,000 lines of Rocq
    • number: All definitions and results are mechanized in Rocq
    • number: Theorem 16 proves PikeVM correctness; no runtime benchmark table is reported
    • limits: The mechanization targets the specified modern JavaScript regex feature set and leaves several extensions (for example additional engine features and termination/complexity questions) as future work. Contextual equivalence is intentionally stronger or more directional than simple observational equivalence in some cases; performance benchmarking is not the paper’s focus. Section 7 explicitly leaves verification of a concrete implementation and a proof of linear step complexity to future work.
    • how much was read: most of it read
    • record id: mechanized-javascript-regex-semantics-2026
  • ModelWisdom TLA+ toolkit (2026)
    • title: ModelWisdom: An Integrated Toolkit for TLA+ Model Visualization, Digest and Repair
    • what: Presents ModelWisdom, an interactive toolkit that links TLC state graphs to TLA+ source, folds and compacts large graphs, summarizes subgraphs with LLMs, and iteratively repairs syntax/property errors using TLC feedback. ModelVisualizer colorizes violated states and properties, supports click-through transition-to-code links, tree layouts, node/edge folding, and lazy rendering. ModelDigest preprocesses graph structure and prompts LLMs with full specifications plus initial/terminal/cycle/frequency summaries. ModelRepair supports single-pass and multi-pass repairs with a history panel, repeatedly feeding TLC errors and revised models.
    • number: implementation comprises approximately 7,000 lines of typed TypeScript and Python
    • number: ModelVisualizer renders one tree at a time and uses lazy rendering/folding
    • number: demonstrations show correction of white-bean decrement from −1 back to −2
    • number: no controlled accuracy, runtime, or benchmark evaluation is reported
    • limits: The toolkit is an interpretability and repair aid around TLC, not a replacement for TLC’s correctness checking; LLM explanations and fixes require human review. Demonstrations use the CoffeeCan example and a deliberately altered postcondition, with no quantitative benchmark of repair accuracy or scalability. Future work targets Promela, Alloy, NuSMV, UPPAAL, and other languages.
    • how much was read: most of it read
    • source
    • record id: modelwisdom-tla-toolkit-2026
  • Move higher-order MVP (2026)
    • title: Formal Verification of Imperative First-Class Functions in Move
    • what: Extends the Move Prover to imperative first-class functions that can be passed, stored in structs and persisted in global storage. Behavioral predicates (requires/aborts/ensures) and state labels specify function-value effects and intermediate memory snapshots; SMT dispatch splits known callees and uses predicates for unknown closures. The verifier supports mutable references/global writes under Move’s alias-free resource model, two-state predicates and quantified state labels. Weakest-precondition inference over Move bytecode generates behavioral specifications for function-valued code, with validation tests covering closures, stored dispatch and state transitions. Static separation of Move memory avoids separation-logic encodings for these calls.
    • number: Closure suite: 19 test modules, about 240 verified functions and 66 expected-error diagnoses
    • number: Tests complete under 5 minutes on GitHub runners; default 40 seconds per verification condition
    • number: Move version 2.4 and MVP Aptos commit pinned in paper
    • number: No larger open benchmark yet; higher-order Move shipped late 2025
    • limits: Function-value dispatch currently enumerates all closure variants reaching a call site, so open or dynamically loaded modules may not scale. State labels are individually bound; sequences of labels and fold-like higher-order iteration remain future work. Nonlinear arithmetic may require user proof hints. Evaluation is a test suite, not a broad benchmark, and Move-specific resource/alias assumptions differ from Rust.
    • how much was read: most of it read
    • record id: move-higher-order-mvp-2026
  • P Verifier documentation (2026)
    • title: P Verifier announcement and two-phase-commit tutorial
    • what: The P Verifier documentation explains a new inductive-proof backend based on UCLID5 and contrasts it with explicit-state model checking. It provides a tutorial for simplified two-phase commit and describes an industrial AWS version generalized to multiple rounds, key-value transactions, shards and snapshot isolation.
    • limits: The industrial proof details are not released in this documentation; the tutorial protocol is deliberately simplified.
    • how much was read: most of it read
    • source
    • record id: p-verifier-documentation-2026
  • P Verifier tutorial (2026)
    • title: P Verifier two-phase commit tutorial
    • what: The P documentation tutorial walks through a simplified two-phase-commit model, specification and test drivers, then points to the proof backend. The page is a practical teaching path from a protocol description to checked properties.
    • limits: Simplified protocol and tutorial scope; not a production proof.
    • how much was read: most of it read
    • source
    • record id: p-verifier-tutorial-2026
  • Partial Contracts Suffice: Sound, LLM-Inferred Regression Verification (2026)
    • what: It shows that a partial contract, one that is enough for the caller, can suffice. The contracts are enforced on the old program. They are then used to prove a regression relation to the new program, relative to a chosen property. A callee may leave unobserved fields unspecified.
    • limits: Use it in a modular way, beneath a top-level guarantee chosen independently. The notes infer that being enough for the caller does not show that all stakeholders’ requirements were found.
    • how much was read: most of it read
    • source; notes: Choosing top-level distributed guarantees and trusted boundaries
    • record id: partial-contracts-suffice-sound-2026
  • Paxos-SB in DistAlgo (2026)
    • title: Specifying Paxos for System Builders: Pseudocode Made Executable
    • what: It transcribes detailed Paxos-SB pseudocode into runnable DistAlgo. At runtime it checks agreement, validity and timeouts. It finds two liveness bugs in the published pseudocode: a non-leader, and both survivors not counting their own vote.
    • number: Table 1: 598 lines total; about 370 excluding comments/setup; core about 200
    • number: original C about 7000 lines; pseudocode about 330 lines in 13 figures
    • number: 3 servers, 2 clients, 100,000 requests each in under 170 s; latency under 1.7 ms; about 10x C runtime
    • limits: These are runtime checks, not proofs. Humans supplied initial values and helpers, and no LLM workflow is reported. The recovery procedure is not implemented separately.
    • how much was read: most of it read
    • source; notes: Specifying Paxos for System Builders: Pseudocode Made Executable
    • record id: paxos-sb-in-distalgo-2026
  • Perennial proof tutorial (2026)
    • title: Perennial Proof Tutorial (Lean)
    • what: The tutorial explains how to write Lean proofs for Go code in Perennial and says tutorial snippets are checked from a canonical Lean file.
    • limits: Tutorial verification was not rerun.
    • how much was read: most of it read
    • source
    • record id: perennial-proof-tutorial-2026
  • PRDT (2026)
    • title: PRDTs: Composable Design and Verification of Consensus Protocols using Replicated Data Types
    • what: Scala components for replicated state with decisions. Two local obligations are enough for consensus safety, and Stainless checks them. Paxos-style compositions and a key-value store are built from the components.
    • number: verification obligations reduced from four to two
    • number: key-value store compared with etcd in one- and three-region setups; leader-failure experiment at 10 s with 5 s timeout
    • number: no proof size, runtime or person-hours reported
    • number: Paper reports verified implementations of multiple Paxos-family protocols
    • limits: Covers the safety of the executable protocol logic only. No theorem that requests eventually get a response. Networking and storage are not proved. An artifact was promised but not found.
    • how much was read: most of it read
    • source; notes: PRDTs: Composable Design and Verification of Consensus Protocols using
    • record id: prdt-2026
  • Scimitar proof decomposition (2026)
    • title: Interactive Safety Verification of Distributed Protocols by Inductive Proof Decomposition
    • what: Introduces inductive proof decomposition and the Scimitar tool for interactively constructing compositional safety proofs. An inductive proof graph decomposes lemmas by protocol actions; counterexample traces are localized and variable slicing hides irrelevant state. Scimitar combines TLC and Apalache to generate counterexamples to inductive proof obligations and TLAPS to validate final proof graphs. The user works backward from a target property, adding support edges and local lemmas; static slicing presents only variables relevant to each node. Five TLA+ protocols were proved, including industrial-scale AsyncRaft with asynchronous messaging and fine-grained local state. The authors report the first invariant effort at that Raft complexity and inspect proof-graph structure as a correctness insight.
    • number: 5 protocol specifications
    • number: AsyncRaft: 12 variables, 11 actions, 638 spec LOC/920 proof LOC, 39 lemmas, median slice 5 variables (0.42)
    • number: AsyncRaft inductive invariant developed in approximately 3 human-weeks
    • number: Other reported proof-development burdens: 1–2 human-months for smaller invariants
    • limits: TLC/Apalache counterexamples use finite parameter bounds and do not themselves prove arbitrary-size invariants; TLAPS validation is required for the final proof. Human guidance remains necessary to add lemmas and edges. Evaluation is on five TLA+ specifications and one implementation; generality to other formalisms is untested. AsyncRaft development took human effort despite automation.
    • how much was read: most of it read
    • source; notes: Scimitar: distinguish the final interactive paper from an older automa; notes: Full live Scimitar configuration inventory (not an evaluated success l
    • record id: scimitar-proof-decomposition-2026
  • Simplifying Safety Proofs with Forward-Backward Reasoning and Prophecy (2026)
    • what: Proves consensus safety of first-order Paxos-family models and an abstract Raft model. Combines forward reasoning, backward reasoning and prophecy (a recorded guess about the future). Checked with mypyvy and Z3. All proofs were written by hand.
    • number: Table 1: 13 model variants, median of 15 runs
    • number: Paxos value-only: Q=4, A=1, B=5 and 0.59 s to universal clauses and 0.43 s
    • number: Fast Paxos value-only: Q=5, A=1, B=7, 1.5 s to 0.8 s
    • number: Raft: Q=7, A=2, B=9, 3.7 s to 2.8 s
    • limits: Safety only, on abstract models. No implementation or progress result. Human effort and lines of code are not reported. No measured rate of successful proof generation.
    • how much was read: most of it read
    • source; notes: Simplifying Safety Proofs with Forward-Backward Reasoning and Prophecy
    • record id: simplifying-safety-proofs-with-2026
  • SoK consensus (2026)
    • title: Systematization of Knowledge: Formal Verification of Consensus Protocols
    • what: A survey that sorts consensus verification into model checking, deductive proofs, code proofs and hybrids.
    • number: over 20 verified consensus protocols
    • number: only about 30% of surveyed works address liveness
    • number: Matrix covers 20+ protocols in abstract and over 30 in conclusion
    • number: Only ≈30% of surveyed works address liveness (§5)
    • limits: It gives no search date range and no count of how many papers were considered, so the reported fraction is not an unbiased census. Table 1 entries need checking against the cited papers.
    • how much was read: most of it read
    • source; notes: Systematization of Knowledge: Formal Verification of Consensus Protoco
    • record id: sok-consensus-2026
  • three-layer agent-skill capability verification (2026)
    • title: Methods for Formal Verification of Agent Skills: Three Layers Toward a Mechanically Checkable Capability-Containment Proof
    • what: Defines two-sided semantics for agent skills—deterministic script-side and nondeterministic LLM-side—and composes three verification layers: static capability analysis, refinement-typed tool-call envelopes, and SMT-bounded checking of runtime traces. A proof-carrying skill bundle is rechecked at bootstrap. Separates script and LLM projections of traces, states containment against declared capabilities, proves soundness and incompleteness for each method, and gives a composition theorem whose sole residual is the LLM’s refusal-to-act surface handled by the runtime biconditional. The implementation includes JavaScript modules, signed evidence files, a bootstrap checker, and a worked SKILL.md example.
    • number: 53-test unit suite and end-to-end CLI (§Abstract, §8.4)
    • number: All 53 tests pass (§8.4)
    • number: Layer 3 takes a few seconds per skill at Kmax=100; bootstrap re-check runs in milliseconds (§9.6)
    • number: Implementation ships as zero-runtime-dependency JavaScript modules (§Abstract)
    • limits: The paper explicitly does not verify model weights, training data, or decoding stochasticity; the LLM is treated as an adversarial nondeterministic oracle constrained by typed dispatch. Method C is bounded by transaction-buffer horizon Kmax, while methods A/B cover only their respective script and dispatch surfaces. Soundness depends on the underlying analyzers, type system, SMT encoding, and runtime biconditional.
    • how much was read: most of it read
    • record id: three-layer-agent-skill-capability-verification-2026
  • TLA+ Examples repository (2026)
    • what: This repository is a corpus of TLA+ specifications and models, with CI and metadata indicating beginner examples, PlusCal variants and TLC, Apalache or TLAPS use. Its README also labels models that intentionally fail on deadlock, safety, liveness or assumptions.
    • number: at commit 6a7b26a: 81 case directories, 424 modules, 233 model configurations, 73 modules with proof metadata
    • limits: Repository metadata and CI status can change; this pass did not run every model.
    • how much was read: most of it read
    • source
    • record id: tla-examples-repository-2026
  • Towards Composable Proofs of Cache Coherence Protocols (2026)
    • what: A Lean proof of safety for the MSI cache-coherence protocol. It shows by trace refinement that the protocol behaves like atomic memory. It is composed from independently verified MI and SI subprotocols, each with local invariants.
    • number: 9228 proof lines excluding whitespace/comments
    • number: three person-days to translate to Bluespec hardware and test
    • number: 100,000 load responses in first testbench
    • number: two 64-KB L1 and one 64-KB L2
    • limits: It covers safety only. The translation to hardware is manual and tested, not proved equivalent. The authors designed the decomposition and the invariants.
    • how much was read: most of it read
    • source; notes: Towards Composable Proofs of Cache Coherence Protocols
    • record id: towards-composable-proofs-of-2026
  • Towards System-Oriented Formal Verification of Local-First Access Control (2026)
    • what: # Whole-paper read: Towards System-Oriented Formal Verification of Local-First Access Control (authored by agents unless marked 🧑) Florian Jacob, Johanna Stuber and Hannes Hartenstein; arXiv2604.23560v1,26April2026,PaPoC2026-related manuscript,8PDFpages. The contribution is a capability-based authorization design and three deliberately restricted Verus implementations. The paper explicitly says its full §3target has not yet been met. Its results concern simplified authorization/query functions assuming a valid eventually consistent chronicle; they do not verify Matrix, Keyhive, a cryptographic hash implementation, or a deployed replication stack. [Q0,Q1,Q3,Q10,Q13] ## Threat model and intended semantics A local-first entity acts on its own replica and exchanges events asynchronously. The threat model permits any strict subset of entities to be Byzantine, f/n<1, including selective omission, equivocation and backdating. Events are assumed authenticated and integrity-protected. The underlying hash chronicle is assumed Byzantine fault-tolerant, append-only and eventually consistent; collision-resistant identifiers fix an event’s causal past. This is the input contract for the authorization layer, rather than a new proof of the replication or cryptographic layer. Eventual dissemination requires the stated chronicle/anti-entropy assumptions; it does not follow merely from having one honest participant. [Q2,Q4,Q9] The mathematical design uses four event kinds:create,grant,revoke,assign. A grant specifies subject, recipient and operation capability; a use presents the grant’s identifier; revocation references that identifier. Events combine an invocation and a downward-closed set of precursor identifiers. The printed identifier contract idealizes collision resistance as equality of identifiers iff equality of events. A valid group has one creation event, no event concurrent with creation, and valid timestamps. Logging appends an event after the current history; joining takes set union. The name query returns the latest authorized assign events, allowing multiple concurrent names. These are the intended §3semantics, not all jointly verified features. [Q5,Q6] Authorization requires a matching authorized grant in the event’s causal past, no matching authorized revocation in its past or concurrent history, and, for a revoke, a referenced grant in its past. Creation and setup precursors are authorized by definition. Extending revocations to concurrent uses prevents an attacker from bypassing a revocation by backdating a new use. It also makes authorization non-monotonic: new information can invalidate an earlier result. [Q6,Q7] The paper distinguishes authorization based only on immutable precursors (“precursive”) from authorization based on the available group including concurrent events (“discursive”). A subtle example is revocationa concurrent with useb, followed by revocationc concurrent witha but afterb: revokinga can reauthorizeb even thoughc followsb. Concurrency is not transitive. Thus a property’s dependence cannot safely be inferred just by looking at direct time order. This motivates distinguishing what may be stored/broadcast from what currently affects queries. [Q7] The three stated security invariants are:precursor-based authorization is unchanged by adding events, while current authorization can change through authorized revocations; a changed query result requires an authorized newly added event; and an invocation unauthorized now remains unauthorized when backdated. These are specifications of the intended behavior. The paper’s explanation that the full Spec.2supports them is not itself a mechanized proof of all Spec.2features. [Q8] ## What the Verus case study reports The three verified restrictions separate the difficult features. First, assign capabilities are fixed before creation and cannot later change. Second, the creator may grant assign rights after creation, but nobody may revoke. Third, assign rights are initially granted and the creator may revoke them, but new grants are not introduced afterward. The third case permits concurrent assign/revoke conflicts; it avoids mutually revoking equally privileged entities. Supporting both grants and revocations in one algorithm, post-creation delegation, query/membership capabilities, self-revocation, public joining, sparse replication and group changeover are future work. [Q10,Q11,Q12] Specification functions describe pure mathematical behavior; executable functions have contracts linking their results to it. Figure4illustrates a log contract accepting exactly the events authorized by the specification, with an explicit fresh-identifier availability precondition. It is a shortened code example with ellipses, not the complete executable implementation. Authors report total and pure queries, precursor authorization as a group type invariant, and the restricted constructions supporting current authorization/revocation safety. If correct replicas eventually hold the same chronicle, deterministic total queries give the same answer. That conditional convergence argument does not prove dissemination, bounded latency, or settlement in a perpetually changing history. [Q9,Q10,Q11] Totality has a material trust boundary. Authors report modifying vstd to add no_unwind contracts, assuming standard-library functions terminate and allocation/randomness system calls do not panic. They also add the assumption that cloning a HashSet preserves its elements, conditional on Rust std correctness. Ghost specifications and proofs impose no runtime checks according to the paper; the paper provides no throughput, memory or latency experiment demonstrating a numerical runtime saving. Its “zero runtime cost” refers to erasing verification annotations, not to a proof that the algorithms execute for free. [Q9,Q11] The evaluation is a proof-of-concept experience report. It supplies no complete table of proof obligations, solver times, source/proof line counts, hardware measurements, test-population results or comparative performance study. The artifact README says verification “should complete in a hand full of seconds”; this is an informal expected duration, not a saved timing measurement. A practical difficulty was replacing unsupported iterator combinators with for loops and proving their invariants; authors call this among the most time-consuming parts. Their claim that Verus is accessible/future-proof is an author judgment, not a measured user-study result. [Q11,Q13,S0] ## Static artifact comparison The paper-linked repository was retrieved at commit3d6bdaf63c192ada9039f4f61127744465827ed0. Its README identifies Verus release0.2026.01.23.1650a05. The Makefile invokes Verus on main.rs, which imports separate modules for the chronicle, three authorization variants, types, helpers and assumed specifications. I inspected the whole Rust source tree. The HashSetclone assumption is explicit; the only external_body in these sources wraps printing. No assume/admit proof escape appeared beyond that declared assume_specification and imported library axioms. This describes these project files, not the full trusted Verus/vstd closure. [S0,S1,S2,S3,S4,S5,S6,S7,S8,S9] The source makes further simplifications concrete. EntityID/EventID areu64, and Chronicle::find_free_id scans from0 for a locally unused identifier under an explicit availability precondition. Events contain the full predecessor set. There is no cryptographic hashing/signature verification, replica transport or join operation in these project modules. Grant/Revoke operations target an entity’s SetName authorization, without the full Spec.2grant-identifier/delegation structure. The immutable case consults setup_grants; the monotonic case permits creator grants; the non-monotonic case treats all entities as initially able to SetName and disables that right when a matching revocation appears in the relevant history. A type invariant requires all stored events to be causally authorized. name’s executable result must equal its specification’s latest concurrently authorized SetName values. These contracts support the stated restricted authorization layer; they do not implement the complete hash-chronicle data type. [S1,S3,S4,S5,S6,S7] main.rs supplies four hand-written scenarios with proof assertions: reject Dave’s unauthorized assignment and retain two concurrent names; reject an unauthorized grant and a use concurrent with its grant; accept a causally valid backdated assignment but exclude it from current name results; and observe{name1}→{name1,name2}→{name1}when a concurrent revocation arrives. I read these scenarios without executing or re-verifying them. Some chronicle clones are executable statements labelled “for verification purposes only”; the general proof-erasure statement should not be read as a measured guarantee that this entire example has no verification-related executable work. [S8] The paper’s reported no_unwind experiment cannot be reconstructed from this snapshot alone: no no_unwind annotation or modified-vstd patch occurs in the acquired project files. The Nix/Cargo metadata point to external Verus/vstd sources, which I did not inspect. Thus the paper’s conditional totality claim remains attributed to the authors; absence in the project snapshot does not establish that their separate experiment failed. The README’s expected fast verification was not reproduced. [Q9,S0,S1,S8,S9] ## Contribution and read scope This paper directly adds a verified-Rust authorization case study to the distributed-systems collection. It isolates the trust placed in replication, cryptographic identity, library specifications and resource-related behavior. Its potential use in evaluating proof-writing agents is my inference: assess the exact restricted capability policy and trusted library additions before calling a whole system verified. The paper has no TLA+ or LLM experiment. [Q9,Q10,Q11,Q13] Read all8PDFpages,37references,all4figures,both complete mathematical specification boxes and all3security-invariant formulas; inspected every page render. The final PDFpage contains all37references. Read all9Rust source files,README,Makefile,Cargo.toml,flake.nix and relevant lock metadata;15static text files acquired withSHA256/Gitblobidentities. External Verus/vstd dependencies and repository scenario images were not inspected. Official arXiv and inventory PDFs are byte-identical. No author execution, compiler, solver or prover run.
    • limits: validauthenticatedeventualchronicle;3simplifiedauthorizationvariants;modifiedvstd/librarytrust;fullcombinedpolicyfuturework
    • how much was read: most of it read
    • source
    • record id: towards-system-oriented-formal-2026
  • TraceFix (2026)
    • title: TraceFix: Repairing Agent Coordination Protocols with TLA+ Counterexamples
    • what: Claude Opus 4.6 turns a task description into a topology of agents, locks and channels. It writes PlusCal for each agent, runs TLC, and repairs from failures. The checked processes become runtime prompts.
    • number: 48 of 48 tasks reach TLC verification; 30/48 pass first try; hard tasks 4/16 first try
    • number: 29 repair attempts: 20 deadlocks, 5 timeouts, 3 syntax errors, 1 undrained channel
    • number: Mean about 594 s and about 4.33 per task - number: 48 tasks, 16 scenario families, all fully TLC-verified; 62.5% first attempt; none over four repairs - limits: Progress is not checked. Repairs for timeouts can reduce fidelity. The runtime monitor checks the topology, not the order of steps. A bounded model-checking pass does not prove that real agents terminate. - how much was read: most of it read - source; notes: TraceFix: generated PlusCal coordination protocols, with important lim - record id: `tracefix-2026` - Verified IronKV issue 8 (2026) - title: recieve_packet spec is underconstrained - what: The issue says a receive transition postcondition leaves store and delegation fields unconstrained, so an implementation rewriting them could still verify. TLC found the gap when exported protocol successors could not be enumerated. - number: The issue reports a two-state TLC trace exposing the store-unchanged predicate failure. - limits: Open issue; report concerns a specific repository revision. - how much was read: most of it read - source - record id: `verified-ironkv-issue-8-2026` - Verifying Graceful Degradation in a Distributed Malware-Detection System with SPIN (2026) - what: The authors model, in Promela, the endpoint side of a Bitdefender-style malware-detection system that falls back from a primary server to a legacy server to a weaker local scan, and check six properties written in temporal logic (five safety, one liveness) plus deadlock freedom with the SPIN model checker. - number: All six properties hold on the core 1 endpoint x 1 scan model: 6,168 states stored, depth 101, under 1 second (Table 2) - number: Streaming model (1 endpoint, 2 scans): 314,527 states; concurrent model (2 endpoints, 1 scan): 22,177,616 states (Table 4) - number: 2 endpoints each with 2 scans ran out of memory, so no result - number: 4 reachability trap claims all violated, showing the checked behaviors occur (Table 3) - limits: Assumes the transport is reliable (no loss or duplication), deadlines are untimed nondeterministic choices, and two detection contracts: the full servers always give the right verdict (A1) and the reduced scan never flags a benign file (A2). Finite instances only; unbounded endpoints and scans need parameterized techniques left to future work. The model is hand-abstracted from the production system and not tied to its code. - how much was read: most of it read - source; notes: ## Graceful degradation in a malware-detection system with SPIN (2026) - record id: `verifying-graceful-degradation-in-2026` - Verus issue 3173 (2026) - title: VerusSync: generated specs and safety lemmas disagree - what: This open issue reports that generated state-machine specifications and safety lemmas can disagree when user code captures macro-generated names or when a generated lemma reads stale state. The issue gives two families of counterexamples where a proof of `false` verifies with zero errors. - number: Two defect families are reported: identifier capture and stale field reads - number: A fresh reproducer reports 2 verified and 0 errors for an unconditional false proof - limits: The report is an issue tracker diagnosis against a specific rolling Verus revision; it proposes hygienic identifiers and shared generation but does not establish a released fix. - how much was read: most of it read - source - record id: `verus-issue-3173-2026` - Verus-TLA repository (2026) - title: verus-tla export (BasisResearch/verus PR #51) - what: This crate embeds TLA temporal predicates in Verus and provides state-machine structures, fairness predicates and verified helper lemmas for safety and liveness proofs. - number: 8 states - limits: README-level documentation; no independent proof audit was run. - how much was read: most of it read - source; notes: R02. Verus temporal libraries, 2025–2026 repository leads - record id: `verus-tla-repository-2026` - Welder (2026) - title: Welder: Compositional Liveness Verification of Cluster Control Planes - what: Welder proves, for each controller, that it makes progress and limits its requests. This statement is called the CORE spec. It then combines the proofs of controllers that fit together. The authors verified the ReplicaSet, Deployment, StatefulSet and RabbitMQ controllers. - number: 1.5 person-years - number: proof lines: CORE 37,487 (ESR 36,215); executable 3,180; model 3,915; trusted 1,081; about seven minutes to check - number: analysis of 188 reported controller bugs claims CORE excludes 178 (95%) - number: seven bugs found during verification; zero in 629 functional, 1,302 controller-crash, 677 Pod-crash tests - limits: Features left out of the success condition are not checked. The proofs assume that faults eventually stop. Controllers that depend on each other in a circle need separate reasoning. Four controllers lack full feature parity with the upstream versions. The evidence on AI is qualitative only. - how much was read: most of it read - source; notes: Welder: Compositional Liveness Verification of Cluster Control Planes; notes: P07. Welder: Compositional Liveness Verification of Cluster Control Pl - record id: `welder-2026` - ACL2 dynamic-stake DAG BFT nonforking (2025) - title: Formal Verification of Blockchain Nonforking in DAG-Based BFT Consensus with Dynamic Stake - what: Formalizes a DAG-based BFT consensus protocol whose validator set and stake can change at every block, and machine-checks blockchain nonforking in ACL2 under a less-than-one-third faulty-stake condition for every active committee. The labeled transition system models validators, certificates, DAGs, network messages, rounds, dynamic bonding/unbonding, lookback active committees, anchor elections/commitments and block generation. Bonding changes become active only after a fixed lookback, resolving the DAG/blockchain circular dependency. The proof establishes interdependent invariants for committee agreement, certificate and DAG nonequivocation, previous quorums, anchor presence/voters/paths/nonforking, and blockchain nonforking. Anchor nonforking uses voter/quorum stake intersection; certificate nonequivocation uses signer quorum intersection, and both are proved together because each depends on the other through committee agreement. The ACL2 development has about 20,000 lines and verifies in under one minute on an Apple M3 Max (under two minutes single-core), applying to arbitrarily long executions and arbitrarily large states. The model intentionally includes deadlocking and other executions beyond an implementation, so safety transfers to implementations as subsets but liveness is not established. - number: faulty stake < one third of each active committee - number: lookback lkbk≄1; committee can change completely every block - number: about 20,000 ACL2 lines - number: under 1 minute on Apple M3 Max 16 cores; under 2 minutes single core - limits: Correct validators follow the abstract protocol and faulty validators are Byzantine; each active committee must have faulty stake at most fstk(w)<nstk(w)/3, with quorum stake qstk=nstk−fstk. Signatures/addresses are idealized and cryptographic details are omitted. The model is nondeterministic and a superset of implementation executions; validators can advance without certificates and deadlock, and the authors explicitly note that proving liveness would require augmenting the model. Only blockchain nonforking and related invariants are proved; performance, synchronization, transaction validity, fairness and implementation behavior are not evaluated. The ACL2 state-transition system and nonforking predicate are trusted modeling boundaries. - how much was read: most of it read - - record id: `acl2-dynamic-stake-dag-bft-nonforking-2025` - Amazon Verus blog (2025) - title: Developing provably correct Rust code with Verus - what: Amazon explains Verus specifications on existing Rust code, human-supplied high-level proof guidance, fast solver feedback and current Amazon/open-source examples including Nitro, Anvil and storage systems. - number: The post says Verus can provide feedback in under a second in practice. - limits: The post is an engineering overview; it does not present a controlled benchmark or a complete deployment proof. - how much was read: most of it read - source; notes: AWS: production proofs exist; published accounts do not attribute them - record id: `amazon-verus-blog-2025` - Astrogator (2025) - title: Towards Formal Verification of LLM-Generated Code from Natural Language Prompts - what: Introduces Astrogator, a verifier for LLM-generated Ansible programs. A user-readable Formal Query Language gives a precise, reviewable specification of natural-language intent; a State Calculus models stateful system effects; a symbolic interpreter and unifier compare generated playbook behavior with the query and report extra assumptions/actions. The formalization separates user intent U from an approved but possibly under-specified query semantics and explicitly defines the unresolved gap p∖s for user review. The State Calculus models attributes, nested elements, stateful functions, reads, writes, conditionals, cases and symbolic loops; unknown reads branch over possibilities, and symbolic lists are approximated by one representative element. Ansible modules are specified in a small module-definition language, while a hand-curated knowledge base maps high-level descriptions such as apache server or zsh configuration file to OS-specific packages and paths. On 1,260 generated playbooks from six LLMs, Astrogator accepts most test-correct programs and rejects most incorrect ones, but under-specified queries permit incorrect programs unless users review reported assumptions. - number: 21 benchmarks - number: 1,260 generated programs - number: 334 correct (26.5%) - number: 277/334 accepted (82.9%) - limits: The formalizer cannot always infer intent from ambiguous natural language, so the user must approve the formal query. The query is intentionally incomplete and the evaluation accepts all programs satisfying it without user review of p∖s. The Ansible compiler does not support all features, especially shell commands, blocks and handlers; symbolic-loop handling is imprecise and arbitrary loops are future work. Ground truth for 1,260 programs is based on tests across Debian 12.11, Ubuntu 24.04.2 and RHEL 9.6 VMs, not a proof of real-world correctness. Knowledge-base single-valued choices cause false rejections when multiple implementations are valid. - how much was read: most of it read - source; notes: ## Astrogator, checking LLM Ansible code against a readable query (202 - record id: `astrogator-2025` - CCF smart casual verification (2025) - title: Smart Casual Verification of the Confidential Consortium Framework (CCF) - what: Industrial experience applying TLA+ specification/model checking, weighted simulation and implementation trace validation to the existing C++ Confidential Consortium Framework. Separate node-consensus and client-history specifications are aligned with production protocol details and incorporated in CI. The paper reports six consensus bugs found/fixed and a clarified read-only consistency limitation, plus tooling/effort and state-exploration measurements. Reconstructs all six safety/liveness cases and the unsuccessful first fix, distinguishes trace compatibility from universal implementation refinement, records granularity alignment via composition/stuttering and incomplete-state reconstruction. Saves all scale/coverage rows, effort figures, counterexample sizes and issue pointers. Preserves TEE/model trust, bounded exploration and non-linearizable read-only semantics; no all-executions C++ correctness theorem is claimed. - number: Six subtle bugs found, five concerning safety and one liveness - number: 400 LoC Trace spec; 88 commits to it and 107 changes to the consensus spec; implementation 63 kLoC C++ - number: six subtle bugs found - number: 63 kLoC in C++ (§2) - limits: §§1–2: CCF runs application logic inside trusted execution environments while treating operators, host OS/hypervisor, network and storage as corruptible. This paper checks distributed protocol behavior under modeled failures, not hardware/firmware isolation, enclave security, cryptography, all 63k C++ LOC, or arbitrary Byzantine behavior of the protected consensus code. Production use in Azure Confidential Ledger is context, not evidence that every production behavior is covered. §§1.1,4,8: Smart casual verification combines formal specification, finite model checking/simulation and tests/trace checks. Consensus spec is unbounded but exhaustive checking restricts terms, requests and reconfiguration sequences. No TLAPS safety/liveness proof for all sizes or universal code-refinement proof is reported. Most CI exploration relies on bounded simulations because sufficiently realistic exhaustive exploration is too expensive. §2: CCF returns transaction results before replication; clients separately query Pending/Committed/Invalid status. A returned result may later be invalidated. Committed read-write transactions are strictly serializable; committed read-only transactions are serializable and may be stale. Pending branches offer fork-like consistency rather than arbitrary results. Broad prose about all committed transactions being linearizable needs the explicit read-only exception. §2: Transaction IDs are lexicographic term/index pairs. If two transactions commit, ID ordering agrees with execution ordering. Ancestor Commit says committed <t,i> implies same-term <t,j>, j≀i, committed. This concerns transaction identity/status, not a proof that any stale read immediately observes the newest committed write. §2.1: CCF customizes Raft with signed Merkle-root transactions, messaging without RPC correspondence, optimistic sentIndex advances, express catch-up, CheckQuorum, bootstrapping/reconfiguration and retirement/ProposeVote. A transaction is committed only after a subsequent signature is committed. The actual combined protocol needs verification; citing the base Raft proof does not establish these extensions. §2.1 reader qualification: Early description says an AE-ACK carries the last transaction in the follower log, while the Inaccurate AE-ACK bug/fix later constrains that index to the end of the received AE. The historical/protocol-description distinction must be retained rather than treating the early sentence as the final safe response rule. §§2.1,4: Reconfiguration needs majorities in each active configuration, rather than a majority of their union. A removed node remains retiring until retirement information is safely committed for future leaders. CheckQuorum steps down an isolated leader, but absent delivery/scheduling assumptions this is not a theorem that all executions make progress. §4: Consensus has 17 actions/13 variables, 12 local-state mappings plus network. Parameterization includes every nonempty initial node subset with any member as initial leader. Locally initiated timeout/signature/candidacy/step-down choices impose no clock synchrony. LogInv compares pairwise committed-log prefixes; AppendOnlyProp prevents committed-prefix rollback over time. Another 27 properties include MonoLogInv, requiring term increases only after signatures. §4: Simulation explores behaviors to bounded depth under a time quota; authors manually downweight failures to promote forward progress. Q-learning was implemented in TLC but no state-hash feature set beat manual weighting. More progress-rich traces may help find bugs but do not constitute exhaustive failure coverage or proof of liveness. §5: Client model uses append-only history and logBranches, independent of node count. History includes read-only/read-write requests/responses and status responses, but omits status requests/Pending replies. A simple shared value appends transaction identifiers so conflicts and observations are visible. It is a deliberately selected application workload, not a proved reduction of all arbitrary CCF application semantics. §5: A new branch can be any prefix of an existing branch containing the last committed transaction. Requests may execute at any still-active leader/term. PrevCommittedInv checks same-term committed ancestor statuses; ObservedRoInv demands that a subsequently committed read-only response observe a read-write transaction whose response preceded its request. The latter expectation is falsified and documented, not a proved CCF invariant. §6.1: Scenario driver serializes consensus execution deterministically and mocks governance/networking/other components, injecting loss/reordering/partition/delay. Original 13 scenarios and about 1.6k unit-test/2k Python end-to-end LOC precede the effort; Table 1 gives later exact scope counts. Initial fuzzing was abandoned for insufficient interesting coverage. Driver/mock accuracy is a boundary, as demonstrated by retirement bugs. §6.1: Driver uses a global logical ordering clock; distributed Lamport/vector alternatives are suggested but not implemented here. Fifteen added logging statements capture stable states at message and role-change points, immediately after a global lock for state changes. Constant-space values such as log lengths are recorded, not full log entries. Production logging compiles out, so the checks use instrumented test executions rather than continuous production monitoring. §6.1/§6.5: Traces initially remove/deduplicate bootstrapping events because early consensus spec omits that phase; later specification is expanded to model bootstrapping more faithfully. These describe successive coverage stages. A successful preprocessed trace validates only its retained observations and modeling assumptions, not excluded initialization behavior. §6.2: Trace spec checks existence of a spec behavior consistent with observed events/values: T∩S is nonempty. Nondeterministically reconstructed hidden state is existential. A successful finite trace check is evidence for those observations, not proof that all completions, all execution traces or unlogged state transitions meet the spec. If logging or mappings omit a decisive distinction, an incorrect implementation could remain compatible. §6.2: Send actions constrain current state, invoke high-level action and assert matching successor messages. Network changes from set to multiset to represent duplicate/resend occurrences. Trace network abstractions also explore ordering/duplication/loss guarantees. Such abstraction choices affect what is observable and accepted; they are not runtime network guarantees inferred from traces. §6.2.1 Listing 5: UpdateTerm·HandleAppendEntriesReq composes two model actions into one implementation receive. IsFault·Next admits unlogged network faults before a step; send-response events may stutter high-level variables when already modeled by another action. Composition hides intermediate states and stuttering changes observation granularity, so correctness depends on the mapping retaining semantically important events. Merely making a mismatch disappear is not an independent proof. §6.2.2–6.3: Start with a happy-path trace, add many assertions and cross-references, debug source and formulas. Invalid traces may indicate bogus logging, incorrect mapping, specification error or implementation bug; failure lacks an ordinary model-checking counterexample. Longest matching prefixes, unreachable-state graphs, failing subformulas and an unsatisfied breakpoint support diagnosis. §6.4: DFS stops after finding one compatible behavior, avoiding BFS enumeration of alternatives; a consistency trace goes from about one hour to under a second. This is an author example without trace-size distribution or controlled speedup suite, and does not mean all traces validate in under a second. Existential acceptance is essential to that optimization. §6.5: Logging/driver enhancements took about one day. Consensus alignment/tooling took two engineer-months over four months, including TLC composition/DFS/debug support, discrepancy diagnosis and abstraction design. Writing about 400 lines of Trace was minor; Table 1 counts 369. Trace saw 88 commits and consensus spec 107 changes. This is observed project effort, not a controlled productivity study. §6.5: Client consistency validation uses REST observations without source instrumentation, reconstructs other clients’ hidden transactions from observed IDs, and took about one engineer-week over two weeks, mainly by CCF experts. Smaller spec, previous experience and reused TLC changes confound a simple comparison with initial consensus effort. §7 Table 1: Approximate state counts/rates are measured on Azure DC8s v3. A log line is largely equivalent to a model action, according to authors, not a formal equality of semantic coverage. Different abstraction sizes, bounds, durations and distinct/generated-state counting prevent treating orders-of-magnitude state counts as a calibrated defect-detection probability. §7: Six serious consensus bugs comprise five safety issues and one liveness issue, found by combined modeling, source scrutiny, trace mismatch, simulation and functional/end-to-end reproduction. They are not six independent discoveries by model checking alone. Read-only non-linearizability is an additional documented consistency ambiguity and accepted behavior, not a seventh fixed consensus bug. §§7–8: Authors report all six fixed before user impact/customer reports; software had already been deployed. One-node-at-a-time operational reconfiguration masked the election bug, and absence of an incident from the first bad commit fix was attributed to chance. No external incident audit, current repository verification or independent bug reproduction was done in this reading. §§8–9: Paper chooses model checking for developer accessibility rather than deductive proof, despite compute cost. AI-assisted proof search is future possibility with a reference to neural theorem proving, not an experiment using LLM agents. Related-work sentence says IronFleet and Verdi both proved Raft; reader qualification: IronFleet uses a Paxos-based replicated state machine, so do not propagate that comparison as fact. - how much was read: most of it read - source - record id: `ccf-smart-casual-verification-2025` - ChonkyBFT (2025) - title: ChonkyBFT: Consensus Protocol of ZKsync - what: Presents ChonkyBFT, a partially synchronous committee BFT protocol for ZKsync with one voting round, single-slot finality, quadratic communication, and n≄5f+1. Safety, validity, and partial-synchrony progress are proved by quorum and timeout lemmas. The Quint specification and Apalache symbolic checking found pseudocode type/definition errors and attack paths; an 18-lemma inductive invariant was checked for bounded parameters. A deployment evaluation measures failure-free throughput, latency, resource use, and replication lag. - limits: At most f Byzantine replicas with n≄5f+1; authenticated reliable point-to-point channels, secure signatures/hashes, and partial synchrony after GST. Liveness additionally assumes block synchrony, periodic retransmission, bounded clock drift, and eventual correct leaders. Formal Apalache checks restrict to six replicas, at most one fault, three views, bounded message/QC sets, so they are model-level evidence. Performance tests are failure-free and exclude block synchronization. - how much was read: most of it read - source - record id: `chonkybft-2025` - Compositional Inductive Invariant Inference via Assume-Guarantee Reasoning (2025) - what: This work splits a TLA+ protocol into components with assume-guarantee contracts (each component assumes something of the others and guarantees something in return). It uses Endive to search for local inductive invariants. It then proves safety with TLAPS for arbitrary instances. - number: two-phase commit: global search 34.82 s, 107 proof steps; local searches 15.44/30.43/6.13 s - number: Mongo Static Raft: global search fails, manual 17-conjunct invariant, 1686 proof steps; local proofs total 372 steps, only one of three local searches succeeds - number: Two-phase commit: global search 34.82 s, 10 conjuncts, 107 proof steps; components 15.44/30.43/6.13 s - number: Mongo Static Raft: global search fails; manual 17-conjunct invariant, 1686 proof steps; components total 372 proof steps but only one of three searches succeeds automatically - limits: Humans split up the spec and write all the contracts. It proves safety only. It uses abstract TLA+, not the MongoDB code. The authors did not measure effort. - how much was read: most of it read - source; notes: Compositional Inductive Invariant Inference via Assume-Guarantee Reaso; notes: Compositional Inductive Invariant Inference via Assume-Guarantee Reaso - record id: `compositional-inductive-invariant-inference-2025` - Daenerys (2025) - title: Destabilizing Iris - what: Extends Iris so assertions can directly mention program expressions that are deterministic, terminating and read-only. Connects Z3 results, obtained by hand, to Rocq proofs. - number: earlier RefinedC bitmap proof needed about 300 lines of bitvector reasoning; Daenerys proves not a single bitvector lemma manually - number: ports of existing Iris examples took at most a few hours each - number: RefinedC bitmap proof needed around 300 lines of manual bitvector reasoning; Daenerys proves not a single bitvector lemma manually - number: Porting existing Iris examples took at most a few hours each - limits: Trusts Z3 for facts obtained outside Rocq. Automatic conversion between Rocq and SMT is out of scope. Works on a defined ML-like language, not deployed code. Reports no solver run times. - how much was read: most of it read - source; notes: Destabilizing Iris (Daenerys); notes: Destabilizing Iris (Daenerys); notes: Concrete problem records - record id: `daenerys-2025` - Formal requirements engineering and large language models: A two-way roadmap (2025) - what: A vision paper on how LLMs can help create, explain and translate formal requirements. It has a worked example of a bounded sender/receiver protocol, modeled in PROMELA and checked with SPIN. - number: passing model: 77 states, 86 transitions, 128.730 MB; failing model 52 states - number: maximum of ten messages - limits: It checks safety within bounds only. Message loss and corruption are excluded by construction. There is no proof that the model matches the Python code. LLM translation is future work. The ChatGPT-3.5 examples were edited illustrations. - how much was read: most of it read - source; notes: Formal requirements engineering and large language models: A two-way r - record id: `formal-requirements-engineering-and-2025` - LAW (2025) - title: The LAW theorem: Local Reads and Linearizable Asynchronous Replication - what: The paper proves that no replicated register can have all three of these: a local read (a read with no messages), linearizability, and a guarantee that operations finish despite async delays and one crash. It designs almost-local reads (batched read validation) in Hermes, ZAB and Raft variants. - number: Raft-ALR 2.6x baseline throughput at 2% writes, 1.8x at 5%; up to 156 million requests/s - number: ZAB-ALR within 4% of ZAB at 1% writes; Hermes-ALR within 11% at 1% writes - number: 5 CloudLab servers, one million keys; reads batched up to 128 - limits: A human wrote a mathematical proof about a mathematical register (deterministic servers, one active operation each, at most one crash). The correctness of the read algorithms is argued in prose. The Raft baseline relaxes linearizability, so the performance comparison is an upper bound. There is no LLM, no code proof and no person-hours. - how much was read: most of it read - source; notes: Added related work: The LAW theorem: Local Reads and Linearizable Asyn - record id: `law-2025` - Lightning TLA+ model (2025) - title: Model Checking the Security of the Lightning Network - what: Formalizes Lightning payment channels and the security property that honest users retrieve their correct balance in TLA+, then uses stepwise refinement to make TLC model checking feasible. Proves an abstraction of blockchain time using zones/timed-automata ideas and proves that single-channel and multi-hop models can be checked separately. A secure ideal payment-system specification serves as the refinement target; TLC checks representative models and simulation checks larger abstractions. - number: five representative models checked - number: up to four hops and two concurrent payments - number: model C5: about 108 states and 12 hours - number: another C5 variant: about 108 states and 13 hours - limits: The checked property is balance security, not all Lightning properties such as griefing or denial of service. Models abstract cryptography, blockchain confirmation and some adversary capabilities; only a small representative model selection is exhaustively checked because larger state spaces become impractical. The paper leaves a complete theorem-prover proof and implementation connection for future work. - how much was read: most of it read - - record id: `lightning-tla-model-2025` - LLM human-readable PFV proofs (2025) - title: Towards LLM-based Generation of Human-Readable Proofs in Polynomial Formal Verification - what: Argues for using LLMs to draft human-readable explanations of polynomial formal-verification proofs, illustrated with induction and BDD size examples, while insisting that a formal reasoning engine must validate every generated claim. The paper places PFV in a resource-bounded setting for adders/multipliers and describes induction prompts for two-variable and three-variable monomial sums and totally symmetric Boolean functions, where BDD size is linear or quadratic under stated structures. It deliberately probes a multiplication-function answer: ChatGPT first gives a misleading variable-ordering claim, then the author identifies the complexity error, showing why LLM prose cannot be trusted as proof. Proposed future directions include retrieval-augmented proof context, chain-of-thought and feedback from formal tools, and application to modern data structures. - number: adders over 1,000 bits cited as PFV case - number: f2/f3 induction examples - number: O(nÂČ) symmetric-function BDD bound - limits: This is an invited position paper with examples, not a validated LLM benchmark. ChatGPT 4o outputs can hallucinate and even the paper's displayed answer contains an empirically plausible but complexity-theoretically incorrect claim about multiplication BDDs; all results require BDD/PFV engine checking. Examples concern well-studied Boolean functions and do not establish general proof synthesis, scalability, or correctness of generated text. No runtime, success-rate or human-study measurements are reported. - how much was read: most of it read - - record id: `llm-human-readable-pfv-proofs-2025` - LLM plan verification with NuSMV (2025) - title: Bridging LLM Planning Agents and Formal Methods: A Case Study in Plan Verification - what: Introduces an LLM pipeline that translates natural-language plans into NuSMV Kripke structures and LTL properties, then uses model checking to classify plan validity on a simplified PlanBench task. The method maps facts to Boolean variables, natural-language initial conditions to init, action preconditions/effects to guarded transitions, and a stage variable to enforce action sequence; goals become LTL reachability properties such as F(goal). NuSMV bounded model checking labels generated models valid (SAT), invalid (UNSAT) or unknown (parse/model failure). A one-shot GPT-4o/GPT-5 comparison reports formal-verification metrics against direct LLM judgments and analyzes unknown handling, syntax versus semantic fidelity and risk-sensitive precision/recall. - number: GPT-5 one-shot: 95.89% accuracy, 99.44% precision, 93.34% recall, 96.30% F1, 6.87% unknown, 47.08 time units - number: GPT-4o one-shot: 52.06% accuracy, 59.19% precision, 45.54% recall, 51.48% F1, 34.61% unknown - number: direct GPT-5 baseline: 99.59% accuracy/F1 with no unknowns, illustrating comparison mismatch - number: direct GPT-4o baseline: 80.37% accuracy, 79.95% F1 - limits: The benchmark is simplified and reduced to binary validity; it does not explain invalidity reasons or test broad software/circuit settings. Unknown outputs are excluded from headline metrics, so treating them differently changes apparent reliability. Syntactically valid models can still misrepresent plan intent and pass verification; one-shot prompting, GPT-5 low reasoning effort and small qualitative semantic analysis limit generalization. - how much was read: most of it read - source - record id: `llm-plan-verification-with-nusmv-2025` - LMGPA (2025) - title: Towards Language Model Guided TLA+ Proof Automation - what: An LLM splits hard TLAPS proof obligations into smaller claims. Symbolic provers check them. The invariant is given as input. - number: 26 inductiveness proofs of distributed protocols plus 93 math theorems (119 total) - number: Distributed protocols (Table 1 p. 13): symbolic-only 38.5%; DeepSeek-V3.2-Exp 50.0% with decomposition (13/26), 0% direct; Claude 3.7 Sonnet 42.3% vs 15.4% direct; GPT-5 42.3% vs 3.8% direct - number: Runtime DeepSeek 9h 14m vs Claude 1h 32m - number: Four decomposition attempts per claim; TLAPS timeouts Z3 5 s, Zenon 10 s, Isabelle 30 s - limits: It tests proving a supplied invariant. It does not test finding one or reading vague requirements. Training leakage is possible from public protocol proofs (Section 4.2). The suite leaves out both learning switches, chord and hybrid broadcast. - how much was read: most of it read - source; notes: LMGPA: prove supplied invariants rather than discover them; notes: TLAPS proof generation grew beyond the January 2025 toy study - record id: `lmgpa-2025` - Maeslant BesW (2025) - title: A Complete Formal Specification and Verification of the BESW Software Control System of the Maeslant Storm Surge Barrier - what: Translates the 15,000-line PLC control design of the Rotterdam storm surge barrier's pump, valve and door controller into an mCRL2 model, then model-checks 40 requirements written as modal mu-calculus formulas. - number: mCRL2 model about 5,000 lines, 4.98e14 states - number: 40 properties: 36 valid at once, 3 valid after rewording, 1 invalid (deprecated requirement) - number: Each property verified within 40 minutes on 2x24-core, 1.5 TB machine - number: Found one design issue: with pump faults, more pumps can run than the power budget allows - limits: Water levels are discretised, not all pump and valve fault combinations are checked, status and log messages and the BOS data protocol are left out. The real model is confidential, so it cannot be reused or re-checked. - how much was read: most of it read - source; notes: ## Maeslant storm surge barrier control software in mCRL2 (2025) - record id: `maeslant-besw-2025` - \mathbf{{\textsc {PyCaliper}}}$: Python-Embedded Infrastructure for RTL Verification and Specification Synthesis. (2025)
    • what: # Whole reading: PyCaliper (authored by agents unless marked 🧑) This CAV 2025 paper supplies hardware specification/synthesis infrastructure and two case studies. Its directly relevant LLM result is GPT-4o ordering existing invariant candidates under formal-oracle checks. The record below separates source reports from reader interpretations and preserves scope limits. Source report: PyCaliper is a Python-embedded domain-specific language (DSL) and infrastructure for register-transfer-level (RTL) hardware specification, verification-backend integration and invariant synthesis. The paper contributes an extensible common specification/oracle interface and two case studies. Its algorithms build on existing incremental invariant synthesis and counterexample-guided inductive synthesis (CEGIS). Reader assessment: no new soundness/completeness theorem, mechanized correctness proof of the framework, or general distributed-system verification result is presented. The framework delegates checks to existing proof engines. [Q1, Q2, Q13] Source excerpt — §1 Related Work and Figure 1; physical PDF p.3, printed p.410, paper.raw.txt:96: text PyCaliper on the other hand, is not a veriïŹcation tool in itself: our main contribution is Python-embedded infrastructure that enables programmatic RTL speciïŹcation and interfaces with (SVA and BTOR2)-based veriïŹcation engines. We use these veriïŹers as oracles to implement invariant synthesis techniques such as syntax-guided synthesis via CEGIS [3] and incremental invariant synthesis [11,36] (the latter itself uses an approach based on PDR). Source report: SpecModule/Struct/Group/Logic/LogicArray mirror RTL modules and signals. input, state and output mean global assumptions, state invariants and output assertions. A miter is two copies of the design; eq and conditional eq relate their signals, while inv is a single-copy assertion. The displayed inductive obligation is input(S) ∧ state(S) ∧ T(S,Sâ€Č) ⇒ state(Sâ€Č) ∧ output(Sâ€Č). Reader qualification: this is preservation under the assumed invariant; the formula does not itself show that every reachable initial state satisfies state. The SVA harness includes clock/reset assumptions, but the paper does not provide a separate base-case proof or a complete initialization-semantics argument. Correct results depend on correct assumptions, RTL mapping, translation, solver and oracle handling. [Q3, Q4, Q7, Q8] Source excerpt — §2.1 Specifications and Figure 2; physical PDF p.4, printed p.411, paper.raw.txt:141: text Inductive Specification. Inductive speciïŹcations in PyCaliper consist of three components: input, state, and output blocks. These correspond to global assumptions, the state invariants, and output assertions, respectively. In general, the input, state, and output functions can be thought of as predicates over the state of the RTL design. Source examples: Figure 2 gives a parameterized FIFO specification for no stale-data leakage: equal control signals and pushed input data, equal pointers and selected live storage entries, and equal output data when nonempty. These are printed schematic examples with omitted code, not separately measured case studies. Figure 3 uses @unroll(2): assume two chosen input constants at step 0 and assert the adder output at step 1 while reset is deasserted. Reader qualification: the printed Python randomly chooses constants before the bounded check, so that illustration alone does not cover every input pair. It computes sum(vals) % MAX with 32-bit constants, but MAX is undefined in the displayed excerpt; the exact wrap modulus is unspecified. [Q3, Q5] Source excerpt — §2.1 bounded specifications, Figure 3; §2.2; physical PDF p.6, printed p.413, paper.raw.txt:197: text Example 1. Figure 3 provides an exam- ple for an Adder module in which the simstep function speciïŹes that the output with two (randomly chosen) inputs a and b equals a + b modulo wrap-around. Source report: elaboration introspects Python objects and resolves hierarchical paths, e.g. a UART tx_fifo.wr_ptr. Parameterized FIFO depth/width can be packaged as a Python library. Section 2.3 presents input-side and output-side implication obligations under a relation R and illustrates FIFO refinement to a Counter. Only synchronous lock-step module transitions are currently supported; stuttering is discussed as a more general form. Reader qualification: the displayed implications alone are not a full transition-simulation proof; initialization and preservation of R are not separately established in this paper. The printed FIFO/Counter relation is preserved in rendered transcriptions without correcting its direct pointer/incdec equalities. [Q5, Q6, Q7] Source excerpt — §2.3 lock-step restriction; §3.1; Figure 4; physical PDF p.8, printed p.415, paper.raw.txt:264: text PyCaliper currently supports reïŹnement proofs where both M1 and M2 mod- ules transition synchronously in lock-step. In general, reïŹnement relations may allow one module to stutter, i.e., not transition while the other module tran- sitions. Such stuttering reïŹnement [16,32] can be used to relate two modules that have similar functional behaviors but diïŹ€erent timing behaviors. For exam- ple, Burch-Dill reïŹnement [33] allows veriïŹcation of a pipelined processor design against its non-pipelined counterpart. Source report: the SVA backend emits a clock/reset harness and a k-step counter, compiles assumptions and assertions, and invokes the licensed Jasper FPV App through TCP/Tcl. Its oracle enables/disables assumptions, covers/checks properties and retrieves traces. The BTOR2 backend uses Yosys lowering with memory flattening, hierarchy removal and technology mapping, retains signal-name correspondence, symbolically unrolls the design and checks bit-vector formulas with Boolector. Other engines/solvers are proposed through interface/operator extensions; the paper does not report an implemented SymbiYosys backend. Reader assessment: the comparison measures two concrete integrations; it does not verify translation correctness or establish equivalence of all engine results independently. [Q7, Q8] Source excerpt — §3.1 oracle; §3.2 BTOR2; §4.1; Table 3; physical PDF p.9, printed p.416, paper.raw.txt:306: text PyCaliper currently supports the (licensed) Jasper Formal Property Ver- iïŹcation (Jasper FPV) App [13] as the proof engine. However, we can enable support for other engines (e.g., open-source tools such as SymbiYosys [15]) by implementing the oracle interface. PyCaliper interacts with Jasper FPV via a TCP interface which is used to send Tcl commands (e.g., prove P_asrt for a check queries) and receive responses. Source report: ceqhole searches for a conjunction of conditional equalities selected from a supplied signal list. Its fuel-limited incremental search maintains speculative assumptions and relatively inductive assertions, adds candidates via a strategy, saturates provable assertions, backtracks, and succeeds only when a self-inductive set proves output. Running out of candidates or fuel can fail. ctrlhole searches a bounded-size control-to-dependent-signal lookup table using traces, then checks inductiveness; counterexamples refine the trace set, and unsatisfiable trace constraints increase table size up to a bound. Reader qualification: these are template-restricted searches; unsuccessful bounded search does not show no invariant exists. The two reported experiments do not benchmark ctrlhole/CEGIS. [Q4, Q9, Q10] Source excerpt — §4.2 strategy/failure; §4.3 CEGIS; Figure 6; physical PDF p.11, printed p.418, paper.raw.txt:402: text If veriïŹcation fails, the trace counterexample is added to the set of traces, and the process is repeated again (up to a limit). Adding the trace guarantees that the (incorrect) lookup table candidate will not be produced in a subsequent iteration. Rendered source: Figure 5 prints the dive guard |assrts| − |assms| > f*, but the surrounding §4.2 text says fuel bounds |assms| − |assrts| and that candidates are added only with fuel remaining. Reader diagnosis: the operand order and inequality do not match that prose interpretation. Both versions are saved, including the full four-rule transcription and image crop. This is a discrepancy in the paper presentation; author code was not inspected, so the implemented guard and its behavior are unknown. No repaired rule is asserted. [Q9, Q10] Source excerpt — §4.1 synthesis target; §4.2 incremental synthesis; Figure 5; physical PDF p.10, printed p.417, paper.raw.txt:364: text The algorithm admits a fuel parameter f∗ that imposes an upper bound on |assms| − |assrts| during the search. Intuitively, a higher f∗ allows for more speculative guessing (with higher coverage), while a lower f∗ forces the algorithm to be more conservative. Source report: domain tags are added to an open-source TAGE indirect-branch predictor so an entry is used only in its creating privilege domain. The stated checked property assumes privileged true targets targ_i < BDRY and an invariant that every PRIV-tagged table target is below BDRY; it asserts prev_mode = PRIV ⇒ targ_o < BDRY. Both backends reportedly verify this using 2-induction. Reader qualification: the formal claim is a privileged-target range property under those assumptions. It does not itself assert full target correctness, independence from all attacker-controlled state, whole-processor security, or complete prevention of every branch-target-injection behavior. No attack experiment, independent proof-certificate check or reproduction was performed here. [Q11, Q12] Source excerpt — §5.1 IsoTAGE security property and two backends; physical PDF p.12, printed p.419, paper.raw.txt:428: text We formalize this as a property that says that provided the true branch target in privileged mode (PRIV) is in the valid kernel-code segment (less than a boundary BDRY), the generated prediction is also in the valid kernel-code segment. Formally, we iden- tify the inductive speciïŹcation: Source measurements: Table 4 varies BHT_WIDTH from 4 through 9. SVA total/solve/parse seconds are 4.0/2.6/1.4 at width 4 and 12.7/11.4/1.3 at width 9. BTOR2 is 3.6/2.6/1 at width 4 and 753.9/11.9/742 at width 9; all six rows are saved in evaluation.json. BTOR2 program statements grow 5,465→116,186 and elements 598→14,486. Solving times are comparable in these cases; total BTOR2 time becomes dominated by parsing, and is slightly lower than SVA only at width 4. The authors call the Python-based parser a likely cause; no parser ablation establishes causation. Hardware, software versions, repetitions, run uncertainty and precise timing boundaries are not supplied. These figures support a bottleneck diagnosis for this benchmark family, not a broad solver ranking. [Q11, Q12] Source excerpt — §5.1 IsoTAGE security property and two backends; physical PDF p.12, printed p.419, paper.raw.txt:438: text Interestingly, we observe that the solving times (ST) of the BTOR2 backend (using the Boolector solver [12]) is comparable to SVA backend using the Jasper FPV App. However, the parse time (PT) is where BTOR2 backend falls behind. This is likely due to the fact that we currently use a Python-based btor2 parsing library - we plan to report this result and improve the parsing performance. This insightful comparison was possible due to PyCaliper’s compatibility with both veriïŹcation backends. Source report: DAWG dynamically partitions cache ways to prevent cross-domain information leakage, formulated as noninterference. Prior work manually supplied invariants. This experiment synthesizes k out of 8 cache-way invariants for k=2,3,4 as invariant width increases. It compares built-in random ordering against GPT-4o ordering of existing candidates, given current invariants and the partitioning property. The authors report about 80 Python lines and 30 minutes of human effort to add that strategy. Reader qualification: this LLM supplies a search heuristic; it is not reported to invent the desired property, write arbitrary invariants, prove a theorem or produce a verified Rust/TLA+ specification. Backend oracle checks determine acceptance. [Q12] Source excerpt — §5.1 Table 4; §5.2 DAWG and GPT-4o strategy; Table 5; physical PDF p.13, printed p.420, paper.raw.txt:467: text We attempt two strategies for selecting the invariant candidate order: random (in-built) and a custom (rudimentary) neural strategy. In the latter, we prompt an LLM (gpt-4o) to provide an order of candidates, providing the current set of invariants and the cache partitioning property as context. Implementing this strategy with PyCaliper required ∌80 lines of Python code and around 30 min of human eïŹ€ort. Source measurements: Table 5 reports means ±σ over 20 runs using the SVA backend and Jasper FPV. For k=2, random/neural verification calls are 16.7±2.3 / 14.3±2.6 and nodes 5.5±0.6 / 4.9±0.9. For k=3, calls are 101.6±47.1 / 54.0±21.8 and nodes 13.3±5.5 / 8.5±3.9. For k=4, calls are 785.7±91.2 / 163±74.2 and nodes 54.3±4.8 / 11.6±8.6. Reader assessment: this shows lower mean search/oracle effort in three configurations on this design. The paper does not report end-to-end wall time, LLM/API cost, exact prompt/model snapshot/temperature, random seeds, fuel setting, success/failure counts or held-out designs. It supplies no statistical significance test or measured generalization claim. These counts cannot establish overall speedup or cost savings after LLM overhead. [Q12] Source excerpt — §5.1 Table 4; §5.2 DAWG and GPT-4o strategy; Table 5; physical PDF p.13, printed p.420, paper.raw.txt:484: text We use the SVA-backend with the Jasper FPV App as the veriïŹcation engine. We see that even our very rudimentary neural strategy outperforms the random strat- egy, likely by being able to detect a pattern in the invariants using the provided context. The takeaways from this experiment are twofold. Firstly, PyCaliper allows leveraging industry-scale backends as veriïŹcation oracles in an invariant synthesis task. Secondly, PyCaliper uses the Python ecosystem to enable easy prototyping of new ideas. Reader synthesis: directly useful for LLM-assisted formal-verification evaluation: separate a heuristic candidate proposal/order from a trusted verification oracle, constrain the search language, expose assumptions and search budgets, and distinguish oracle-call count from end-to-end runtime/cost. Its specification reuse, two-trace security properties and assume-guarantee/refinement interfaces are adjacent to distributed-systems proof engineering. No distributed-system, Verus, verified Rust or TLA+ case is evaluated; transfer to those settings is an inference requiring separate implementation and evidence. In particular, its lock-step-only refinement would not by itself cover the stuttering commonly needed when relating systems with differing step granularity. The strongest topic-specific evidence is the measured GPT-4o candidate-ordering experiment, not autonomous specification/proof generation. [Q6, Q7, Q9, Q10, Q12] Source excerpt — §5.1 Table 4; §5.2 DAWG and GPT-4o strategy; Table 5; physical PDF p.13, printed p.420, paper.raw.txt:490: text Secondly, PyCaliper uses the Python ecosystem to enable easy prototyping of new ideas. Reading audit: all 18 physical PDF pages (printed 408–425) and all 784 LF of the complete layout extraction were read, including §§1–6, acknowledgments, disclosure, references 1–56 and the license through EOF. All six figures and five tables were inspected in their rendered pages; the remaining pages were viewed in contact sheets after their text was read. No appendix occurs in this PDF; external publisher attachments were not queried. Literal physical-page quotes remain separate from rendered-math/table transcription. PDF metadata duplicates/omits author names, so identity follows the rendered title page. The title page displays artifact-available and reusable badges; no artifact execution or independent evaluation was done here. No author implementation file, scientific dataset/result artifact or checkpoint was inspected/loaded; no formal tool was run. Measurements and proof successes are source-reported. Independent source review and final aggregate acceptance remain for the parent. [Q0, Q1, Q2, Q3, Q4, Q5, Q6, Q7, Q8, Q9, Q10, Q11, Q12, Q13, Q14, Q15, Q16, Q17] Source excerpt — Open-access license; physical PDF p.18, printed p.425, paper.raw.txt:683: text Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License
    • limits: Source-reported backend success under input/state/harness assumptions; template- and fuel-limited invariant search; lock-step-only refinement; no separate framework soundness/translation proof; Figure 5 fuel-guard/prose discrepancy; privileged prediction range versus complete attack security; three DAWG synthesis settings averaged over 20 runs; no end-to-end LLM time/cost or generalization evidence; no reproduction.
    • how much was read: most of it read
    • source
    • record id: mathbf-textsc-pycaliper-python-2025
  • Model Checking and Synthesis for Optimal Use of Knowledge in Consensus Protocols (2025)
    • what: # Model Checking and Synthesis for Optimal Use of Knowledge in Consensus Protocols (authored by agents unless marked 🧑) Alpturer, Huang and van der Meyden use MCK to check whether small synchronous consensus protocols decide as soon as their available information permits, and synthesize concrete decision predicates from knowledge-based programs. The contribution is empirical and methodological. They “do not attempt to give a full characterization or a proof” of general optimality (§1, p.3, Q3). The 22-page arXiv 2505.02353v1 is the full version of the PODC 2025 paper, ACM pp.131–140, DOI 10.1145/3732772.3733552 (Q37; saved arXiv metadata). No new parameterized proof or new synthesis engine is presented. ## Assumptions and specification (authored by agents unless marked 🧑) The system has synchronous message rounds and two layers: an information exchange defines observed state, messages and updates; a decision protocol chooses noop or a decision. Failures are crashes or sending omissions. A crashing agent can send an arbitrary subset of its messages in the crash round and then sends nothing; an omission-faulty agent can omit sends but receives messages sent to it (§3, pp.5–6, Q6–Q7). “Byzantine Agreement” names the coordination problem here; the experiments do not evaluate arbitrary malicious message values, asynchronous scheduling or a cryptographic implementation. The base simultaneous agreement specification requires at most one decision per agent, agreement at the same time among nonfaulty agents, and a decision value initially held by some agent, possibly faulty. The paper explicitly says “termination is not a requirement of this specification,” while reporting additional termination checks in its scripts (§4, p.6, Q8). Eventual agreement permits different decision times (§8, Q20). These distinctions matter when calling a synthesized result correct. Optimality is relative to the same information exchange and failure model, comparing runs with identical initial preferences and failure patterns (§4, p.7, Q9). The paper distinguishes an optimum protocol, which decides no later than every competitor, from an optimal protocol, which no competitor systematically improves. This is not optimality across arbitrary messaging designs or execution costs. The semantic order as printed compares every agent; this record does not silently narrow its quantifier to nonfaulty agents. MCK uses finite variables and ordered binary decision diagrams. The chosen clock semantics gives an agent its current observable variables plus the time, rather than perfect recall. Synthesis replaces boolean template variables with local predicates equivalent to knowledge tests (§6, pp.8–9, Q11–Q12). Uniqueness under clock semantics and the optimality characterizations are attributed to prior theory, not proved anew. EBA’s simpler knowledge-based program P0 also requires technical side conditions on information exchange: learning 0 through decision-message chains and suitable possibilities involving nonfaulty agents (§8, pp.11–12, Q20). ## Concrete cases and results (authored by agents unless marked 🧑) Four SBA information exchanges are modeled: FloodSet, FloodSet plus current received-message count, the Count variant plus previous count (“Diff”), and the concrete Dwork–Moses protocol. Two EBA exchanges, Emin and Ebasic, respectively send decision values and additionally send initial 1 messages with a count. The models have parameters n agents, t maximum failures and the decision-value set. The main FloodSet/Count timing table fixes two values (§§7–11, Q13–Q28). FloodSet retains values seen and broadcasts their union. The naive earliest-knowledge hypothesis t+1 fails at n=3,t=2. Revised Eq 2 uses time=n−1 when t≄n−1, otherwise t+1; model checking and synthesis agree in the instances checked (§7.1, pp.9–10, Q14–Q15). The authors report an all-n proof in companion work [7]; this read does not include that proof (Q17). Adding the current message count exposes the early condition count≀1, meaning only the agent’s own message was received (§7.2, Q16). Diff gave no stronger SBA stopping condition than Count in checked cases, although previous-count memory can help a different EBA specification (§7.3, Q18). The printed Count formula needs reconciliation at a boundary. Eq 3 uses “time = t” in its t≄n−1 branch (§7.2, p.10, Q16), whereas FloodSet Eq 2 uses time=n−1 (Q14). At n=3,t=3,time=2,count=3, Eq 2 is true and Eq 3 false. Count adds an observation while retaining FloodSet’s values and clock; its stated earliest condition should not require later knowledge on that account. No-crash histories allow count 3 even when t=3 is the failure upper bound. This is a reader-derived discrepancy in the printed conditions, not a replayed MCK counterexample or a refutation of the companion theorem. The benchmark inputs needed to resolve it were not obtained. The source’s formulas are retained unchanged in Q14/Q16 and static-witnesses.json. There is a second printed EBA ambiguity. Ebasic’s jd update stores 0 on receiving 0 and otherwise ⊄, but its decision 1 rule includes “jd𝑖 = 1” (§9.2, pp.12–13, Q22). Under that update description the jd=1 branch cannot be reached. I have not silently repaired the update or inferred which rule the actual model used. Appendix A gives a complete FloodSet synthesis example for n=3,t=1,two values. It uses finite time 0..3, communicates while time<2 and has four decision templates for knowledge times 1 and 2 (pp.18–21, Q32–Q35). The reported output makes both time 1 predicates false; at time 2 the predicate for v is values_received[v], with 0 taking priority in the decision code. The authors report that the accompanying formulas all hold (p.22, Q36). State at time m means information after round m; the decision follows in the next modeled round (§7, Q13). This accounts for the appendix’s AX3 completion check. The appendix checks ordinary and uniform agreement, validity and termination at AX3, and knowledge predicates. Its printed agreement formulas compare values when both agents have decided; they do not explicitly require simultaneous decided flags (Q34). Thus the displayed formulas alone are not a direct check of every SBA clause. The knowledge-based theory may establish simultaneity; no counterexample to the synthesized protocol is claimed. Likewise the finite AX3 termination check is not a general unbounded liveness proof. The appendix uses currently ALIVE agents in knowledge tests, which should not be casually substituted for permanently nonfaulty agents without the cited crash-theory correspondence. ## Evaluation and limits (authored by agents unless marked 🧑) The experiments used one core of a 3.7 GHz six-core Intel Core i5 with 256 KB L2, 9 MB L3 and 32 GB memory. The final run’s timeout was 10 minutes (§10, p.13, Q23). Early exploratory trials sometimes ran 5 hours or 2 days; those are not the table timeout. No MCK build/version, BDD variable ordering, repetition count, variance, raw trial set or memory measurements are supplied. The measured costs are model-checking and synthesis runtime, not consensus latency or deployment throughput. All three timing tables are transcribed with printed values and converted seconds in numeric-evidence.json: 16 parameter rows in Table 1, 15 in Table 2 and 6 in Table 3, totaling 118 timing cells. TO remains a timeout rather than a measured 600-second completion. Representative results show the steep scaling: - FloodSet at n=5,t=2: checking 34.635 seconds, synthesis 162.015 seconds; synthesis times out at n=5,t≄3. Checking still finishes at n=6,t=1 in 72.863 seconds, while n=6,t=2 times out (Table 1, Q24) - Count at n=4,t=2: checking 23.328 seconds, synthesis 120.892 seconds; synthesis times out for t=3/4 and both tasks time out at n=5 in the listed rows (Table 1) - Diff at n=3 takes roughly 258–304 seconds depending on failure bound/rounds; Dwork–Moses times out for every listed n=3 case. Both time out at n=4,t=1,one round (Table 2, Q26) - Emin EBA synthesis succeeds through the listed n=3 cases, with crash costs 31.219–178.142 seconds and omission costs 11.371–66.735 seconds. Every n=4,t=1 cell times out. Ebasic succeeds only at n=2 in Table 3 (Q28) Table 3’s prose says Emin scales to 4 agents before blowup, then names Emin again for the worse count-containing model. The table has no successful 4-agent row, and §9.2 attributes the extra count to Ebasic. This record preserves the cells and flags the prose ambiguity instead of recording 4-agent success or swapping labels without evidence. Receiving/general omissions are reported to have similar successful cases, but no separate timing rows are provided (§11, Q28). For comparison, the authors report 125 seconds for purely temporal SAT-based SBA checking of Dwork–Moses at n=5,t=4 (§13, p.16, Q30). This checks a different obligation with a different algorithm from the BDD epistemic runs, so it is not a like-for-like solver speedup. They suggest quadratic messages and BDD size explain the difficulty; the paper does not measure a causal ablation. Their conclusion is appropriately limited: “a manual proof of correctness and optimality will” still be needed for all numbers of agents and failures (Q30). ## Contribution to the requested topic and evidence scope (authored by agents unless marked 🧑) This adds concrete epistemic verification and protocol-synthesis benchmarks for distributed consensus, including examples where stronger local observations permit earlier decisions but make automated analysis harder. It supports a workflow of synthesizing small instances, checking hypotheses on larger finite instances, then proving the general claim manually. That workflow is the authors’ proposal; this paper does not demonstrate LLM agents. There is no Verus or verified Rust experiment. Appendix A calls its nondeterministic transition construct “refinement calculus/TLA action style” (Q33); it does not report TLA+/TLC verification. For LLM-generated specifications and proofs, I infer evaluation lessons from the record: state the failure and information-exchange scope, declare observation/recall semantics, distinguish agreement from simultaneous agreement, inspect every printed guard and boundary case, separate finite checking from general proofs, and retain timeouts and source/script mismatches. These are reader-derived lessons, not measured LLM results. Read every one of 1099 layout-text lines, all 22 pages, all 39 references and the complete appendix input/output. Inspected 11 contact sheets and fullsize pages 10,13–15,19–22; the paper has three tables and no figures. The bundle retains 44 literal excerpts with line/character/page anchors, 19 diagnostics, all 37 timing rows and raw hashes. Local/official PDFs are byte-identical. The paper identifies no benchmark archive/repository link. The primary MCK site links a related consensus demonstration. I read its page/loader and all 551 logical lines (550 newline characters) of four static source scripts: FloodSet, optimized FloodSet, Count and Dwork–Moses. They are pinned by content hashes and fetch times; no direct association with the paper’s benchmark version was established. The demo FloodSet/Count scripts read and update w in place, allowing later senders to forward values received earlier in the same round; Appendix A instead snapshots old_w before delivery. Demo FloodSet crash delivery is also selected per value. These differences prevent treating the demos as interchangeable benchmark inputs or evidence against the paper’s reported results (Q38–Q44, D19). No demo Verify action or stored .result output was invoked or loaded. Two MCK subpage links returned 404 and were not retried within five minutes. No author code, compiler, model checker, prover or solver was executed; no serialized scientific/model/results data were loaded. Reported checks and synthesis outputs are statically inspected author results, not independent reproductions.
    • limits: Synchronous rounds, crash or sending omissions, and finite MCK clock semantics using current observations and time. Optimality is relative to a fixed information exchange and failure model. Base SBA omits termination. EBA P0 requires technical information-exchange side conditions. The paper checks finite instances and supplies no all-n proof. Count Eq. 3, the Ebasic jd update and Table 3 prose have unresolved printed discrepancies; the appendix lacks an explicit simultaneity formula. Related static demo models differ from the appendix; the exact benchmark revision and independent reproduction are unavailable.
    • how much was read: most of it read
    • source
    • record id: model-checking-and-synthesis-2025
  • On Temporal Verification of Stateful P4 Programs (2025)
    • what: Defines P4LTL temporal properties over completed packet processings while retaining register state between packets. Models arbitrary input packets and changing table actions, optionally constrained by symbolic control-plane assumptions. Constructs a BĂŒchi transaction product in which the specification automaton advances only at packet return, reducing violations to fair feasible traces. A proof sketch establishes the abstract correspondence; p4tv implements P4-to-Boogie translation, ghost instrumentation and an Ultimate Automizer extension. Evaluation checks19 temporal tasks on nine programs plus assertion checks/scaling, identifying two naturally occurring property failures and three injected defects. Records exact packet-boundary/old/free-variable semantics, register initialization and control-plane scope, product transitions/acceptance and proof-sketch qualifications, refinement algorithm and implementation trust, all Table2/3 cells, actual versus injected bug distinction, p4v approximation and assertion instrumentation, rapid scaling growth, and source specification/prose inconsistencies including vacuous liveness formula. Separates local P4xos checks from whole Paxos consensus verification.
    • limits: §3: Environment is a serial infinite loop of complete packet processings, persistent registers outside loop, nondeterministic packet fields each iteration and metadata initialized per P4-16. Table applications are nondeterministic action choices. This abstracts a single programmed switch; no proof of interleaved pipeline concurrency, simultaneous register read/modify/write races, multiple switches, queue dynamics or actual hardware refinement is supplied. Packet time is not wall-clock time. §§2/3/7/8: Register initialization is part of each verification configuration. P4NIS failing task9 leaves count unconstrained; successful invariant/assertion examples assume valid/zero initialization or add recovery logic. Persistent arbitrary initial values differ from independently re-randomizing registers every packet. Results under initialization assumptions do not show a real deployment meets those assumptions. §§3.2/4: CPI constrains table keys/actions/parameters, allows symbolic sets of entries and changes between packets. Empty CPI permits every modeled rule. Property checked is assumption implies desired property; it can hold if assumption is impossible. Authors do not report systematic assumption satisfiability/vacuity checks or prove a real controller always enforces CPI. Table2 needs CPI for tasks6,7,8,16 only. §4.1: Predicates are evaluated at packet boundaries: terms normally after processing; old(t) at ingress start after parsing; valid(h) records validity after parsing, hit/apply record occurrence during processing. old(key) and old(para) expressly arbitrary. fwd(t) is egress_spec==t syntactic sugar, so packet-output/architecture correspondence matters. Free variables describe nondeterministic values intended to cover all names; scope/stability must be preserved when translating specifications. §§4/6/7.2: Boundary-only temporal properties can miss transient within-packet violations. Assertion checks use a shadow variable initialized true per packet and capture the assertion at its program point, then check its boundary value. This is an explicit instrumentation workaround; the native P4LTL language still cannot directly observe arbitrary internal events. Correct instrumentation and all relevant visits are part of the trust boundary. §5.1: Product keeps program/specification location pairs, updates specification only on TR(s), uses assume true on other statements, and accepting locations require spec acceptance plus TE/TR boundary. Fair means BĂŒchi acceptance (infinitely recurring accepting states), not automatic network-delivery, scheduler or adversary fairness. Liveness assumptions about infinitely many particular packets are written explicitly in the property. Infinite repeated packet processing is the base execution model. §5.1/Appendix A: Theorem5.1/A.1 is an abstract correspondence with an informal proof sketch, not a mechanized proof of P4 semantics, Boogie translation, instrumenter or executable checker. Projection deletes only true steps imposed by non-return transitions; a return transition labelled true must remain. Appendix switches the named if/only-if directions, and reverse construction retains TE(s)√TR(s) while operational product advances spec on TR(s) only. A rigorous proof should distinguish statement/boundary indexing and establish infinitely many returns; no concrete tool-unsoundness counterexample claimed. §5.2/6: Algorithm1 reuses counterexample-guided refinement from cited fairness-modulo-theory work: select accepting trace, test feasibility, return genuine trace or remove a generalized set of infeasible traces, finish when none remain. No universal termination/runtime bound or translation correctness theorem provided. Trust includes P4/Boogie modeling, ghost instrumentation, LTL conversion, automata/refinement/feasibility engine and underlying reasoning tools. Code/proofs not run in this reading. §6: Prototype fully supports V1Model but limited TNA/PSA. Authors claim model transferable with more detailed P4 processing; future architecture support is not demonstrated full support. State explosion remains. About10000C++/JavaLOC and selected small benchmark programs do not establish production-scale coverage. §8 pp.228–229: Printed P4NIS liveness consequence is conjunction over ports i of GF(phi_sp -> fwd(i)), under GF(phi_sp). This is weaker than GF(phi_sp AND fwd(i)): infinitely many non-specific packets satisfy every implication regardless of forwarding. Alternating specific/non-specific packets with no fwd(i) satisfies the displayed formula while violating the natural-language goal. This is a semantic observation about the printed specification, not a run of artifact specifications. §4’s earlier liveness example has a different stronger shape. §8: NDN weak-until formula is activated only after a data packet was forwarded; it then forbids repeated data forwarding until a matching forwarded interest. It does not by itself forbid the first unsolicited data forward before that trigger, nor require eventual forwarding because W permits no future interest. Task6’s separate property covers interest-before-data. Universal free hash variable is not a proof of hash collision freedom or data-name authentication. §5.1 Figure5/§7.2 Table3: Figure5 prose says status becomes0 when hdr.cnt<0, while listing/automaton tests>0; record follows code when describing example. Table3 says acceptor stored round strictly less than current round, while adjoining prose uses≀ under zero initialization. Strict< would fail on equal zeros; cannot silently interchange these properties. Printed description/code discrepancies do not establish implementation bugs. §7: Dataset has nine manually selected programs and manually authored properties; artificial bugs inserted in CPI/task8 and code/tasks15,18. Natural failures tasks9,13 are author-reported findings without external maintainer confirmation/production exploit in paper. 14 verified tasks and five counterexamples are outcomes for specified models, not whole programs certified correct. §7.2: Temporal comparison with four prior tools is a support limitation discussion; measured assertion comparison runs bf4 and an approximate p4v implementation from bf4 work because original p4v unavailable. Vera limited user assertions and Aquila unavailable. Spurious counterexamples are relative to chosen persistent-register configuration, not evidence prior tools unsound for their broader nondeterministic model. p4tv is much slower but more precise for these stateful examples. §7.3: Program and specification scaling varied separately on P4NIS ports and acceptor index clauses. Curves grow rapidly; Figure8 about8600s near64ports and Figure9 about24000s near32clauses, approximate visual readings only. Easy false properties return inabout90s for CNT8/16, so falsification speed does not imply comparable proof scaling. No cross-product scalability, latency budget or large production network study. §7: Hardware i5-12400 2.50GHz/32GB; no repeat counts, confidence intervals, error bars or user specification effort measurements given. Main temporal tasks10–1260s; assertion acceptor-safe1701s, so21min maximum applies only Table2. P4xos acceptor/learner predicates are local state/order/vote checks, not an end-to-end Paxos agreement/liveness proof under crash/message-loss/reconfiguration. No Verus/Rust/TLA+ implementation theorem or LLM-agent evaluation. §7.1/Table2 task8: Printed task8 checks property6, data is forwarded only after a corresponding interest. Reported trace receives interest then drops data. A dropped data packet alone cannot violate this only-if safety condition. Preserve author-reported counterexample outcome, but it does not demonstrate violation of the printed property without more trace/specification detail. This inconsistency does not establish tool unsoundness.
    • how much was read: most of it read
    • source
    • record id: on-temporal-verification-of-2025
  • P2FGPT (2025)
    • title: Constructing formal models of cryptographic protocols from Alice&Bob style specifications via LLM
    • what: A prompt-based pipeline that reads a security protocol written as ‘A -> B: message’ steps and writes the declarations part (types and functions) of a ProVerif model. ProVerif is a security-protocol checker. A checker step runs ProVerif’s parser, and a repair step re-prompts the LLM on syntax errors.
    • number: dataset: 4 ProVerif demo protocols cut into 53 + 25 + 14 + 14 = 106 sub-protocols
    • number: syntax-correct rate with GLM4.0: 65% (generator alone) to 82% (with repair step)
    • number: repair step helped GLM4.0 only; it made no difference for Llama3-8b and little for Qwen2.5-7b
    • number: content score (BLEU/F1) with GLM4.0: BLEU 0.34 to 0.39, F1 0.58 to 0.62 with repair; Qwen2.5-7b BLEU 0.61, F1 0.60
    • limits: Generates only declarations, not the protocol steps or the security goals the user cares about; no check that the model says what the protocol says, only that it parses and looks like a reference text. Prompts were tuned by hand on GLM4.0 and transfer poorly to other models.
    • how much was read: most of it read
    • source; notes: P2FGPT, Alice&Bob to ProVerif (2025)
    • record id: p2fgpt-2025
  • Personalised ADL Verification (2025)
    • title: A Personalised Formal Verification Framework for Monitoring Activities of Daily Living of Older Adults Living Independently in Their Homes
    • what: Builds personalized LTL/pLTL models from home sensors, interviews, layouts and context, then uses NuSMV to check participant-specific daily-living requirements and deviations. The workflow segments sensor traces into overlapping 20-minute subtraces, constructs personalized models and checks temporal properties for showering, refrigerator use, medication and physical-layout constraints. Two participant case studies expose both genuine deviations and sensor/model limitations.
    • number: Study recruited 10 participants aged 67–97; case studies use two participants
    • number: Sensor data are segmented into 20-minute windows with 10-minute overlap
    • number: Participant A Property 1 violated on Aug 28 and Property 2 on Aug 25; Participant B medication property violated on Nov 22
    • number: Three motion sensors malfunctioned, about 1% of data
    • limits: Models assume one participant; sensors provide event evidence rather than semantic guarantees, and pets/visitors add noise. Data cover a small participant subset and one to three weeks; three malfunctioning motion sensors (about 1% of data) were excluded. Temporal requirements may need refinement for routine variation and sensor blind spots.
    • how much was read: most of it read
    • record id: personalised-adl-verification-2025
  • Position: Vibe Coding Needs Vibe Reasoning: Improving Vibe Coding with Formal Verification (2025)
    • what: Advocates a side-car system that maintains specifications during conversational code development, selects lightweight verification tools, feeds actionable results to the coding model, and lets developers review constraints. Distinguishes verifier-feedback filtering (Type I), postprocessing/constrained generation (Type II), and collaborative specification maintenance (Type III). A small TypeScript prototype hooks Claude Code changes and instantiates four templates: exhaustive switches, discriminated unions, shared union aliases, and satisfies Record guards. Toy order-status examples show missing shipped UI handling and missing cancelled processing.
    • number: 4 specification templates
    • number: 2 bugs in the order-status toy example
    • number: no quantitative evaluation
    • limits: This is a position paper with a small proof of concept, not a quantitative effectiveness study. Verification is currently syntactic checks and compiler acceptance; broader formal tools, provenance, and application-specific specification maintenance remain proposed work. Its claims about inevitable decay and general bug absence are arguments, not experimentally established guarantees. Compiler checks apply only to the chosen templates and modeled type constraints.
    • how much was read: most of it read
    • source
    • record id: position-vibe-coding-needs-2025
  • PoWER (2025)
    • title: PoWER Never Corrupts: Tool-Agnostic Verification of Crash Consistency and Corruption Detection
    • what: PoWER encodes crash consistency as a precondition on each storage write: every durable state introduced by a partial write must be permitted by a ghost permission. Prophecy-based storage views and recovery-equivalent writes simplify proofs. A bounded-bit corruption model and an eight-byte corruption-detecting Boolean support atomic data/checksum updates. CapybaraKV in Verus and CapybaraNS in Dafny demonstrate the method, with coarse concurrent KV variants and performance comparisons. Records exact permission quantification, prophecy flush semantics, state versus transition and blanket versus single-use permissions, all four write strategies and concurrency restrictions. Includes correspondence-proof trust boundaries, CRC corruption bounds, Tick-Tock counterexample and CDB protocol, full type/LOC/startup/resource tables, all workload setups and adverse performance cases. Separates conditional detection from arbitrary-media-error recovery and reported proofs from independent proof replay.
    • number: CapybaraKV 5,531 executable / 14,255 spec+proof / 5,244 trusted lines; CapybaraNS 278 / 673 / 414
    • number: verification 54 s single-thread, 23 s eight-thread for KV, 12 s for NS
    • number: Table 2 KV total: 5244 trusted, 14255 spec/proof, 5531 implementation lines; notary 414/673/278
    • limits: Core technique requires Hoare pre/postconditions, ghost variables and quantification over crash states. Each asynchronous write requires all chunk-wise old/new durable outcomes to satisfy its permission; executable annotations erase. Soundness depends on every actual storage mutation using the controlled API, correctness of the storage model and a meaningful allowed-recovery predicate. A permission that allows all states proves no useful crash property. Natural storage semantics distinguish readable last-written bytes from outstanding writes. Atomic persistence chunks can survive independently until flush. The prophecy model instead stores read_state and one prophesized durable_state; write updates all readable bytes and chooses a subset of chunk subwrites for durable state. Flush constrains these two states to agree without changing either in the ghost model. This is a logical modeling device, not a runtime ability to predict crash outcomes. The authors report a Verus proof implementing the prophecy model over a natural model using prophecy variables. The PoWER-to-Crash-Hoare-logic proof in Rocq/Perennial is metalogical and trusts a translation of PoWER semantics, since PoWER was not implemented in Rocq. The Verus correspondence to crash invariants is entirely machine-checked within Verus. Formal theorem bodies are in artifacts; this reading examined paper explanations only. Crash states can be specified through rec(bytes), commonly allowing pre-operation or post-operation abstract state. Transition permissions instead authorize pairs of durable states. Blanket permissions cover arbitrary recovery-equivalent transitions; single-use permissions authorize a mutating transition once and are consumed or invalidated. A blanket permission can manufacture single-use permissions only for its allowed transitions. Initial recoverability and all permission constructions remain proof obligations. Tentative writes change only addresses irrelevant to rec and need no value-specific proof. Committing writes are a single aligned atomic chunk, typically after flushing tentative data, so only old/new durable states matter. Recovery writes rely on idempotent recovery that overwrites all possibly torn bytes on retry. In-place writes can use weaker specifications with many allowed outcomes, but the authors have no verified examples or helper-library support for that category. Atomic PoWER adds durable ghost resources owned by atomic invariants, proof callbacks and completion objects for consumed transition permissions. Completions witness an issued/applied operation even if another thread later changes its key. This extension needs concurrency facilities beyond the minimal core features; a tool-agnostic core does not imply arbitrary concurrent proofs in plain sequential Dafny. Concurrency allows multiple readers, or disjoint statically allocated storage regions with exclusive access during writes. It excludes read/write or write/write overlap within one region because callers must know its current logical state. Sharded wrappers establish linearizable individual create/read/update/delete/list operations, not cross-shard transactions. The reusable inner implementation still supplies a transactional API to wrappers. Corruption is modeled by a fixed device bitmask with at most c potentially faulty physical bits. A zero mask bit reads correctly; a marked bit can return either value independently on each read. The trusted CRC axiom distinguishes byte strings at Hamming distance 1 through c. Current ECMA CRC-64 implementation uses c=1 for arbitrary lengths; the cited c=3 for data shorter than about1 GiB is not exploited. Detection is conditional on that device-wide bound, not a guarantee against arbitrary bursts, malicious rewrites, rollback or unbounded media failure. Reader qualification: integrity proofs must cover corrupted data and checksum bytes, repeated/noncontiguous address mappings, and the chosen CDB codeword distance under the same physical-bit bound. The paper reports verified checking and a trusted CRC library; it does not derive an unrestricted cryptographic collision-resistance guarantee. Detecting a mismatch permits reporting corruption, not necessarily repairing damage or preserving availability. Tick-Tock’s old-checksum/new-data mismatch after a crash is not a small-bit corruption event relative to the old data. CRC(D0) can collide with CRC(D1-prime) even if D1-prime differs by only bounded media corruption from D1, because D0 versus D1-prime may differ arbitrarily. The paper gives a logical counterexample to the algorithm in its model, not an independently reproduced NOVA-Fortis artifact exploit. CDB stores one of two known eight-byte values CRC(0) and CRC(1), with aligned crash atomicity and sufficient corruption separation assumed/proved for the primitive. Two data/CRC slots accompany it. Write the inactive slot and checksum, flush, atomically switch CDB, flush. The selector identifies the committed slot independently of potentially matching stale checksums. This costs extra storage and flushes; it does not remove hardware atomicity assumptions. CapybaraKV values contain a fixed-size item and a list of fixed-size elements, with fixed-size keys. The abstract state has on-abort and on-commit maps. Ordinary operations affect the latter; abort restores it from the former; commit publishes it to the former. A crash during commit may commit or abort, while other uncommitted operations abort. Reads within a transaction see tentative operations, so visible results need not already be durable. Implementation uses main/item/list tables, per-field CRCs, validity CDBs, copy-on-write updates and a physical redo journal. Journal commit writes a CRC of pending entries then flips a CDB; replay installs operations and clears the journal. Volatile key index and free lists rebuild on startup. Correctness depends on recovery traversal, bounds, allocation and CRC checks, not merely the commit selector. Capacity is statically allocated at initialization with maximum key/item/list counts and sizes. No dynamic resizing, partial-value updates or range queries. All keys reside in a volatile Rust HashMap and must be indexed again at startup. Designed target is small records on tens of GiB of dedicated PM in a cloud-storage service. Prototype integration into an Azure Rust system is reported, not evidence of production deployment of all verified variants. Trusted pmcopy bridges Verus and compiler-generated representations. It requires repr(C) and derive(PmCopy), implements PmSafe/PmSized/Clone/PartialEq, generates specifications and static layout assertions checked by Rust. PmSafe includes numeric types, bool and char; composites require safe fields. Casts still require correct layout, valid discriminants/values and prior corruption checks. Compiler assertions caught a u128/i128 layout change; this is a concrete consistency check, not a proof of the macro or compiler. CapybaraNS stores a 64-bit logical timestamp and last hash. Advance increments and atomically persists them using CDB; Sign signs their binding. A trusted C# wrapper supplies CRCs, cryptography and serialization. This paper does not supply a complete distributed-notary protocol, a cryptographic implementation proof, remote attestation argument or availability theorem. Counter overflow handling and full security assumptions require the external specification. PM model permits independent eight-byte chunk reorderings until flush; backend write uses PMDK non-temporal stores or mov followed by clflushopt/clwb, and flush uses sfence. It deliberately overapproximates strongly ordered clflush and same-cache-line hardware ordering, including potential compiler reorderings. Eight-byte alignment/atomicity, backend calls and hardware behavior remain trusted. PoWER can use other models; current model is not a universal storage-device specification. Table 2 counts unverified pmcopy source but not its generated code. KV trusted count includes mock byte-vector PM plus Windows/Linux backends, concurrency and sharding wrappers. Trusted versus proved LOC therefore should not be interpreted as executable core size alone. Reported proof/code ratios are2.6 KV and2.4 NS; LOC is not a measure of specification adequacy. KV design, implementation and verification took about1.5 years by a team of experts and newcomers; headcount and person-time are unspecified. After that experience, porting the PM spec to Dafny took under an hour, porting helper lemmas about an hour, and implementing/verifying NS about nine hours after its spec and C# wrapper were already written. This is author experience, not a controlled productivity comparison. On Linux6.9.3 with i7-11850H eight physical cores and32 GB RAM, KV verifies in54s with one thread or23s with eight; NS takes12s with one. Appendix expects KV1–2min serial or15–40s parallel on other hardware. Paper gives no independent proof replay in this reading and no controlled comparison against alternative verification approaches. Performance setup is a two-socket32-core machine with128 GB RAM and one128 GB Optane DC PMM, Debian Trixie/Linux6.12.10. All KV runs use the sharded variant with one shard per thread. Redis client/server run together but retain communication overhead; RocksDB uses memory-mapped files and non-temporal log appends; Viper preallocates enough capacity except in utilization measurement. Different supported features and durability architectures affect comparison. Microbenchmarks use25M records,64-byte keys,1 KiB values and8-byte list elements. Append adds16 elements per record in random order; read-list returns the entire list; trim removes it. Other operations run once per record. Figure2 uses logarithmic latency axes and95% confidence intervals. KV matches or beats RocksDB but Viper is faster on several operations, including most writes; Redis is slowest. Windows/Azure20 GiB battery-backed DRAM tests run only KV, with up to2× improvement; other systems lack Windows support. YCSB uses15M keys,24-byte keys,1140-byte values and five executions per system. RunE range queries are omitted and RunA/RunB partial updates become full-value updates. X is uniform75% updates,5% read-modify-write and20% reads; Y/Z use50/50 or5/95 read/update with90% accesses to10% records. LoadE is omitted only from Figure4 as similar to LoadA. These modified workloads must not be called an unmodified full YCSB suite. At one thread KV is broadly comparable to Viper and often slightly slower. At16 threads it substantially leads Viper on update/read-heavy run phases but not every load phase; the broad prose claim of outperforming other systems needs this figure-level qualification. Viper is tested on one non-interleaved NVDIMM despite optimizations for interleaved PM. Authors attribute scaling issues partly to CCEH semaphore costs nearly doubling1→16 threads. This is reported profiling attribution, not isolated causal proof. Figure 4 read-heavy B/C/D scale better than write-heavy phases. Approximate 16-thread throughput is RunC 3.5 Mops/s, RunB/RunD 3.0, RunA 1.25, LoadA 0.4, RunF 1.1, RunX 0.9, RunY 1.2, RunZ 0.8 and LoadX 0.4. Values are visual estimates. Hash sharding distributes hot keys across shards, so this does not demonstrate performance under all accesses contending on one shard. Full-instance startup fills each store to its own out-of-space point with64-byte keys/1 KiB values; capacities and record counts can therefore differ. KV/Viper startup is seconds because volatile indexes rebuild, whereas RocksDB is milliseconds. Full Redis startup fails with memory allocation error. Table3 utilization instead uses YCSB LoadA and optimally provisions KV at18 GiB with no further growth. Comparing those startup/resource numbers requires keeping these distinct experiments separate. Artifact branch osdi25-artifact and Zenodo15306499 include implementations, scripts and proof guidance; CHL formalization lives in the Perennial repository rather than being bundled. Exact performance reproduction requires at least128 GB Optane, with128 GB DRAM/32 cores recommended; emulation can check workflow but changes performance. Default artifact experiments are smaller than paper runs. No artifact or external proof was executed here; no LLM, TLA+ model-checking or distributed network liveness experiment appears.
    • how much was read: most of it read
    • source; notes: PoWER Never Corrupts: Tool-Agnostic Verification of Crash Consistency
    • record id: power-2025
  • Program Logics Ă  la Carte (2025)
    • what: It builds program logics in Coq by composing reusable descriptions of effects that are already proved. The effects are shared memory, scheduling, nondeterminism, failure and termination. It reconstructs the HeapLang and Islaris logics this way.
    • number: Islaris semantics from about 130 to about 90 lines; proof about 270 lines instead of about 450
    • number: Islaris semantic definition: around 130 LOC down to around 90 LOC
    • number: Proof size: around 270 LOC instead of around 450 LOC
    • number: No person-hours or benchmark pass rate reported
    • limits: It reuses verified components and does not infer anything. Program proofs are still written by humans. Three axioms are declared. No new assembly programs were verified.
    • how much was read: most of it read
    • source; notes: Program Logics Ă  la Carte; notes: Program Logics Ă  la Carte; notes: Concrete problem records
    • record id: program-logics-a-la-2025
  • QuickSilver / D-Escalate / Venus (2025)
    • title: Automating Formal Verification of Distributed Systems via Property-Driven Reductions
    • what: Sound reductions from parameterized models (arbitrarily many processes, large data domains) of agreement-based protocols to small finite models. QuickSilver, D-Escalate and Venus check them. The developer writes a Mercury/Coalition model and a safety formula.
    • number: Table 3.1: 12 Mercury models, 32-99 lines, cutoffs 2-5, 0.059-736.417 s
    • number: Table 4.1: 23 Coalition cases, 78-126 lines, one cutoff 6
    • number: Table 5.1: 10 Venus cases, 34-79 lines, 0.202-1.620 s
    • number: means over 10 runs
    • limits: It covers safety of the parameterized model only. The termination of the agreement primitives is assumed. One cutoff was computed manually. Human modeling time is not quantified.
    • how much was read: most of it read
    • source; notes: Automating Formal Verification of Distributed Systems via Property-Dri
    • record id: quicksilver-d-escalate-venus-2025
  • Remix (2025)
    • title: Multi-Grained Specifications for Distributed System Model Checking and Verification (Remix)
    • what: Refines coarse TLA+ protocol actions into detailed ones where concurrency matters. It mixes levels of detail to keep model checking practical, and checks the model against implementation executions (ZooKeeper).
    • number: six severe bugs violating five types of invariants
    • number: Six deep ZooKeeper bugs found and fixes verified
    • number: abstract: found six severe bugs that violate five types of invariants
    • number: six severe bugs
    • limits: The notes infer that matching the implementation and fixing bugs found by the model checker do not validate the chosen client guarantee, and do not prove liveness for unbounded cases.
    • how much was read: most of it read
    • source; notes: Choosing top-level distributed guarantees and trusted boundaries; notes: Appendix B: Concrete systems and theorem scope
    • record id: remix-2025
  • Reusable Formal Verification of DAG-based Consensus Protocols (2025)
    • what: # Reusable Formal Verification of DAG-based Consensus Protocols (authored by agents unless marked 🧑) Nathalie Bertrand, Pranav Ghorpade, Sasha Rubin, Bernhard Scholz and Pavle Subotić, arXiv2407.02167v2,18March2025. The inventory year2024 identifies the original submission; this read uses the retained2025revision. The authors report TLA+/TLAPS safety proofs for five protocol models by combining three DAG-construction components with two ordering components. The five are DAG-Rider, Cordial Miners, Hashgraph, Eventually Synchronous Bullshark and a minor variant of Aleph. The result concerns Integrity and Total Order; eventual delivery, probabilistic progress and implementation correctness remain outside it (Q0,Q1,Q2,Q12). ## Reading scope and source identity Read all21PDFpages, sections1–6 and51reference entries, all three figures including both panels of Figure2, seven listings and numerical Table1. Individually viewed pages6–16, covering the figures, listings, refinement mapping and numerical table. The paper refers to “Appendix ??” but includes no appendix. References were read as bibliography entries, not recursively read papers. Acquired the paper-linked repository’s complete nontruncated tree and22static blobs at9e4c9629eb283c7c34b6ffcf7956bc72a3e26e5d,22December2024, the latest retained commit before this paper revision. This selects a historical version without establishing that it produced the reported timings. Whole reads cover README and the five component Specification.tla files. Proof files and complete-protocol sources are inspected only in explicitly recorded ranges. Acquisition of a file does not imply its whole read. No author code, specification, checker or solver was executed/imported; no serialized experimental data or model was loaded. ## What is proved and how composition works A vertex embeds its entire rooted causal history, rather than only an opaque identifier. Thus two processes possessing the same vertex have identical histories for it. A separate anchor-agreement property requires processes that have selected anchors for a frame to select the same anchors. Delivering each frame’s previously undelivered causal-history vertices in a fixed deterministic order then prevents duplicate delivery and gives consistent delivery order. A lagging process may deliver a shorter prefix; the proof is not simultaneous equality of local delivery states (Q2,Q3). The decomposition is three construction models, reliable structured, unreliable structured and unreliable unstructured, plus Global Perfect Coin (GPC) and Virtual Voting (VV) ordering. Reliable construction ensures one agreed vertex per position. Unreliable structured construction allows equivocation and uses ratification to agree on a vertex at a position. GPC ordering separately agrees on leader positions; combining these properties establishes anchor agreement. Hashgraph first converts its unstructured events to a structured witness DAG. Reference consistency constrains witnesses’ predecessor references; VV establishes agreement on famous witnesses (Q4,Q6,Q7,Q8). The full protocol maps constants and new state variables into an INSTANCE of the ordering specification. Each construction action performs an appropriate ordering action or leaves its mapped variables unchanged. Protocol-specific refinement obligations remain necessary: five reusable components do not eliminate the proofs connecting five concrete models to them. DAG-Rider and ES Bullshark share reusable components but differ in wave lengths and commit/leader rules. Aleph is explicitly a variant; neither the paper nor its one-line repository README gives a precise delta against every published Aleph rule (Q4,Q9,C6). ## Assumptions and abstractions The system explanation assumes signed identities and fewer than one-third Byzantine processes. Reliable broadcast is weakened to integrity because validity and eventual agreement support liveness. Its model retains the first broadcast for each creator/round; the authors argue a faulty process’s chosen delivered message could equivalently have been sent first. This is an abstraction argument to retain in correspondence work, not a separately measured implementation equivalence (Q1,Q5). Unreliable communication copies a vertex from another local DAG; Byzantine participants can insert arbitrary modeled vertices. Procedures retain input/output behavior while omitting internal loop states. GPC becomes an arbitrary fixed function shared by all processes: randomness, unpredictability and fairness are absent. Agreement of the function’s answers suffices for the stated safety argument; it supplies no probability-one termination theorem or implementation of a cryptographic coin (Q5,Q7,Q8). The retained component models use finite symbolic bounds on waves/rounds or event IDs, with no fixed numerical test instance. Proof claims quantify over their parameters; a single TLC run at one bound would not establish that claim. The record does not independently establish an infinite-execution refinement beyond these bounded model families. The VV component incorporates its reference-consistency premise directly into both the prestate and poststate of Next. Its source proof of that premise therefore depends on the action restriction; a concrete protocol still must justify the mapping (C1–C5). ## Consequential findings in the retained artifact The printed self-referential VertexSet listing is explanatory shorthand. ReliableStructuredDAGconstructionSpecification.tla instead constructs vertices recursively by decreasing round with UntilRoundVertex. That resolves the apparent circular-definition concern for this component. However, its received/added-vertex guards access v.edges, while the actual constructed records contain strongedges and weakedges. This is a static field mismatch in the saved model; no checker error or reachable protocol failure was observed (C1). In the unreliable structured component, Approves(v,u) requires Observes(v,u) and forbids observing every vertex with u’s source and round. Taking that quantified vertex to be u yields both Observes(v,u) and its negation. Thus the literal definition admits no approval. With n-f positive under3f<n, ratification requires a nonempty set of approving sources and cannot occur under this reading. Since ratified vertices initialize to Nil, the displayed agreement property can hold without any ratification progress. This is a reader derivation from the retained definitions, not a claim that the real Cordial Miners protocol fails (C2). The unstructured component’s DonotSeeFork(v,u) has the same self-including universal condition. Taking x=u contradicts its Path(v,u) conjunct. Its Sees predicate consequently cannot witness a seen ancestor under the intended reflexive Path interpretation. This is another source-definition concern to resolve before trusting correspondence to actual Hashgraph behavior; the paper excludes liveness and no safety counterexample is established (C3). VVOrderingProofs.tla contains several named lemma statements without proof text. Most concretely, intInv14 asserts, for integers a,m, that a>=m and m+a>2f imply m>f. The permitted assignment f=1,a=2,m=1 makes both premises true and its conclusion false. The file cites this lemma in its Inv1 preservation proof. The nearby intadd statement has the plausible intended conclusion a>f with strict a>b. This suggests a proof-support defect or mistaken statement in the retained artifact; it does not show a checker accepted a false theorem. The actual preservation goal is a majority-count fact that can be mathematically true even though this cited general lemma is false (C7,C8). The same proof preamble asserts, without accompanying proof text, that every witness has more than2f predecessor sources in the preceding frame. Combined literally with its positive finite frame range and predecessor-frame condition, that leaves no nonempty witness set: a witness of minimum frame would require an earlier witness. This preamble should not silently become an established domain theorem. A simpler nonvacuity concern appears in the VV specification itself: all witness-DAG cells initially are empty, while adding a witness requires more than2f predecessor sources already present. With f nonnegative and no genesis exception, no first witness can be added under the intended typed interpretation. Whole proof closure and tool handling of unproved declarations have not been replayed. These artifact findings limit independent confirmation of the paper’s mechanized-proof claim; they do not refute the high-level decomposition or establish a reachable fork (C5,C7). ## Evaluation and significance Table1 reports, in order reliable structured/unreliable structured/unreliable unstructured/GPC/VV: specification lines403/160/230/272/136; invariants6/6/7/10/18; proof lines460/594/554/822/2120; maximum proof depths10/9/8/9/13; maximum degrees7/8/7/7/11; leaf obligations633/895/665/1302/3316; and checking seconds49/68/74/125/651. Environment:2.10GHzCPU,8GBRAM,Windows11,TLAPS1.4.5. These are author-reported component checks, not reader replications or total timings for every full-protocol refinement. No repeated-run variability or controlled comparison appears (Q10). The authors report approximately14person-months across five people. Their “almost half” proof-effort claim corresponds to reducing an illustrative ten separate construction/ordering components to five reusable ones. There is no controlled person-time baseline or ablation demonstrating a50% labor saving; refinement work and component complexity also differ. A reusable component count is concrete, while a measured causal labor reduction remains unestablished (Q0,Q4,Q10,Q12). This is directly relevant to reusable TLA+ specifications and distributed-protocol proofs. It has no Verus/Rust artifact or LLM-agent experiment. A reader proposal for evaluating proof agents is to score specification correspondence, nonvacuous progress examples, closure of helper lemmas and refinement obligations separately from reported leaf-obligation throughput. The retained field/predicate/lemma issues make those distinctions concrete without treating static concerns as observed solver results.
    • number: approximately 14 person-months across 5 people
    • number: Table 1 spec lines 403/160/230/272/136; proof lines 460/594/554/822/2120; obligations 633/895/665/1302/3316; TLAPS time 49/68/74/125/651 s
    • number: TLAPS 1.4.5 on 2.10 GHz, 8 GB
    • number: Reuse reduces proof effort by almost half
    • limits: Safetyonly;abstractbroadcastandcoin;finiteparameterizedhorizons;implementationrefinementfuturework;retainedsourcefield/predicate/helperlemmafindingslimitindependentconfirmation;nocheckerreplay
    • how much was read: most of it read
    • source; notes: Related addition: Reusable Formal Verification of DAG-based Consensus
    • record id: reusable-formal-verification-of-2025
  • Reusable TLA+ Communication Primitives for Modeling and Verifying Distributed Systems (2025)
    • what: A PlusCal Echo protocol built over reusable channel abstractions (perfect, fair-loss, stubborn). TLC checks eventual delivery, FIN termination and that no message is invented.
    • number: MaxCopies set to two; only Property 3 held under duplication
    • number: no state counts, timings, LOC or hours
    • limits: The checks are bounded model checks. The user handles nondeterministic drops and eventual delivery. The perfect link is FIFO, which is stronger than usual.
    • how much was read: most of it read
    • source; notes: Reusable TLA+ Communication Primitives for Modeling and Verifying Dist
    • record id: reusable-tla-communication-primitives-2025
  • Sync/Async functional distributed verification (2025)
    • title: Functional Reasoning for Distributed Systems with Failures
    • what: Defines twin Rocq-embedded languages Sync and Async to make high-level functional reasoning about asynchronous distributed protocols precise, then proves that compiled Async executions are included in Sync denotations. The authors mechanize the framework and safety proofs for Bosco and Sequential Paxos. Sync is a choreography language whose typed programs are ordered communication steps over role-indexed vectors; its power-set denotation explicitly enumerates message loss, reordering, truncation and arbitrary Byzantine injections. The configuration model separates good, crash-prone and Byzantine nodes and uses a Netwk relation as an executable over-approximation. Finite loop unwinding supports safety proofs for nonterminating protocols. Bosco proofs derive a strong one-step theorem for n>7f and an inductive univalence/agreement invariant for n>3f. SeqPaxos proofs use a weakest precondition UC_D to show once a value is decided, later iterations decide it or abstain when n>2f; the condition is weaker than the protocol’s strongest postcondition and exposes optimization opportunities. Async is a monadic node LTS plus single-use channel LTS; alignment permutes arbitrary interleavings into channel order, and adequacy (Theorem 5.1) follows through aligned traces, big-step semantics and channel-erasure lemmas. The Rocq development is about 2.5k lines and includes endpoint projection/executable extraction.
    • number: Rocq mechanization about 2.5k LoC
    • number: Bosco one-step threshold n>7f; agreement threshold n>3f
    • number: SeqPaxos agreement threshold n>2f
    • number: SimpleVote example n_R=4, f_R=b_R=1
    • limits: Sync excludes branches and loops inside a body, cryptographic primitives, and arbitrary communication order; it therefore targets streamlined communication-closed protocols. Network messages are authenticated, nonduplicated, eventually delivered between correct nodes, and well typed; signatures and parsing are assumed rather than modeled. Byzantine behavior is over-approximated and can inject values it could not know. Safety is proved for finite loop unwindings, not termination/liveness. The Async adequacy theorem is inclusion (compiled outputs are in the denotation), and correctness depends on the stated channel-ordering and synchrony-reduction restrictions.
    • how much was read: most of it read
    • source
    • record id: sync-async-functional-distributed-verification-2025
  • The Coming Need for Formal Specification (2025)
    • what: An opinion piece proposing a workflow. First an English spec. Then several TLA+ models at different levels of detail. Then a formal proof, for example in Rocq, of the components the system depends on most. Finally an LLM audits the rest against the TLA+ spec.
    • number: seL4: 8,700 lines of C, 20 person-years, 200,000 lines of Isabelle (quoting Kleppmann)
    • limits: Opinion only, with no evidence.
    • how much was read: most of it read
    • source
    • record id: the-coming-need-for-2025
  • TLA+ Examples issue 174 (2025)
    • title: Spec claims to check (safety-prop) UnforgLtl but config actually also checks (liveness-props) CorrLtl and RelayLtl
    • what: An open issue in the TLA+ Examples repository flags a mismatch between a Byzantine broadcast specification’s stated safety property and the configuration’s additional liveness properties. It points to the exact TLA+ and configuration lines.
    • limits: The issue is a repository-maintenance report; it does not say whether the extra properties pass or fail, only that the configuration checks more than the description claims.
    • how much was read: most of it read
    • source
    • record id: tla-examples-issue-174-2025
  • Trustworthy agents LLM-FM position (2025)
    • title: Position: Trustworthy AI Agents Require the Integration of Large Language Models and Formal Methods
    • what: Argues for bidirectional LLM/formal-method integration: LLMs automate specification and proof work, while model checkers, theorem provers, SMT solvers, testing and runtime monitors constrain and certify LLM actions. The proposed six-stage pipeline starts from natural-language requirements, auto-formalizes them, runs model checking/theorem proving/SMT, tests edge cases, monitors executions and iteratively refines outputs. It sketches a Coq theorem-prover agent and a miniF2F even-number example. Sections 2–5 distinguish failure modes of LLM-only reasoning (hallucination, non-determinism, no traceability), FM-only workflows (specification effort, scalability and unpredictable environments), and hybrid trade-offs. The auto-formalization workflow creates a proof outline with placeholders, delegates algebraic gaps to external tools and revises failed proof steps. The model-checking discussion targets safety/liveness, deadlock and refinement; theorem proving targets machine-checkable proofs; SMT handles satisfiability; testing and monitoring cover behaviors outside proofs. Appendix A gives explicit Coq interaction steps and an Isabelle/HOL formalization attempt, making the proposal concrete but not an implemented benchmark. The implemented PAT prototype repairs GPT-4o car-lock modeling errors using model-checker traces: leavekey must require an open door, and locking receives explicit owner/key guards. Appendix A also gives Z3 meeting scheduling with missing unavailable-day constraints and a Dafny palindrome specification/implementation; these illustrate semantic alignment risks rather than measured success rates.
    • number: six pipeline stages: auto-formalization, model checking, theorem proving, SMT, testing, monitoring
    • number: Coq workflow has four steps from natural language to verified explanation
    • number: Appendix example uses sum of two even numbers
    • limits: This is a position/conceptual paper with case studies, not a controlled empirical evaluation. It assumes formal specifications and verifiers are available and sufficiently expressive; hybrid integration incurs representation mismatch and complexity. Formal methods can miss unmodeled or emergent behavior, while LLM-generated specifications/proofs still require verifier feedback and possibly human refinement. The Coq example is illustrative and does not establish agent success rates.
    • how much was read: most of it read
    • record id: trustworthy-agents-llm-fm-position-2025
  • Veil (2025)
    • title: Veil: A Framework for Automated and Interactive Verification of Transition Systems.
    • what: It embeds distributed transition systems in Lean. It sends first-order proof obligations to SMT solvers and leaves the rest as interactive Lean goals.
    • number: 16 evaluated cases incl. Rabia, SCP, Suzuki-Kasami, Vertical Paxos
    • number: 1704 non-empty, non-comment lines of Lean; 85 actions and 185 invariants; about 100 lines per file
    • number: 16 benchmarks, 1,704 Lean lines, 85 actions, 185 invariants
    • number: Veil verifies 16/16; 14/16 under 15 s and 12/16 under 10 s
    • limits: It evaluates checking supplied invariants, not finding them. It is not an LLM agent. All its guarantees are safety. The notes record no agent success rate.
    • how much was read: most of it read
    • source; notes: Veil: proofs in Lean with automatic first-order checks; notes: Veil: a promising proof interface, with no agent rate established here
    • record id: veil-2025
  • A Systematic Literature Review on a Decade of Industrial TLA+ Practice (2024)
    • what: The paper reviews 16 papers on industrial use of TLA+.
    • number: 16 papers
    • number: Early design 81%, debugging 44%, implementation 38%
    • number: Only 3 of 16 discuss the model-to-code link
    • how much was read: most of it read
    • record id: a-systematic-literature-review-2024
  • Anvil (2024)
    • title: Anvil: Verifying Liveness of Cluster Management Controllers
    • what: Rust controllers are written as state machines. The authors prove they match an abstract model. They also prove that the model reaches the desired cluster state and then stays there, once the desired state stops changing. They call this eventual stable reconciliation.
    • number: ZooKeeper 1,134 executable / 8,352 model+proof lines; RabbitMQ 1,598 / 7,228; FluentBit 1,208 / 8,395
    • number: total 3,940 executable, 23,975 proof/model, 2,326 trusted lines
    • number: parallel verification 154, 151, 96 seconds
    • number: about 2.5 person-months; first proof about two person-months, later ones about two person-weeks
    • limits: Trusts the temporal-logic embedding, the environment model, the specs of external APIs, Verus and the OS. Assumes faults eventually stop. The guarantee says nothing useful if the desired state changes forever. One bug came from an incomplete trusted spec of the ZooKeeper API.
    • how much was read: most of it read
    • source; notes: Anvil: Verifying Liveness of Cluster Management Controllers; notes: P06. Anvil: Verifying Liveness of Cluster Management Controllers
    • record id: anvil-2024
  • Behavioral Programming liveness (2024)
    • title: Keeping Behavioral Programs Alive: Specifying and Executing Liveness Requirements
    • what: Adds a must-finish state idiom to Behavioral Programming so b-threads can specify liveness directly, with GBA-game and MDP-based execution mechanisms. The paper maps 18 liveness patterns among 55 Dwyer patterns to executable b-threads, proves live-run compatibility, translates b-programs to generalized BĂŒchi automata, and uses either SCC winning strategies or reward-guided MDP policies. Evaluation covers railway-level crossing and parameterized Maskable PPO, plus Sokoban.
    • number: all 18 liveness Dwyer patterns are mapped and verified with BPpy
    • number: Maskable PPO convergence table reports 20 repetitions across parameter configurations
    • number: parameter dimensions vary freight/maintenance approaches, maintenance railways, and k-spacing
    • number: GPU evaluation uses NVIDIA GeForce RTX 4090
    • limits: The GBA mechanism assumes finite-state executable models; MDP experiments focus on one liveness b-thread and use learned policies that may become infeasible as state complexity grows. Verification assumes must-finish states eventually exit, and RL results are proof-of-concept rather than universal policy guarantees.
    • how much was read: most of it read
    • record id: behavioral-programming-liveness-2024
  • CSP retrospective (2024)
    • title: The Challenges and Triumphs of CSP Based Formal Verification
    • what: Roscoe looks back on CSP, a notation for describing processes that run in parallel and talk to each other, and its model checker FDR. He covers a two-player-game encoding, a primary/secondary consensus handover protocol for blockchains with malicious nodes, a way to check deadlock freedom from the sum of component state spaces, and the Coco tool used by ASML.
    • number: Coco Platform is in use at ASML for photolithography machine software (as stated by the author, no figures)
    • number: the author’s naive CSP blockchain model could not hold a realistic number of blocks, agents or keys (state explosion)
    • number: token-invariant deadlock check on a 3-component example: state space of 6 component states, one nontrivial invariant (t4) proves deadlock freedom
    • limits: Reflective paper written for CSP experts: no benchmarks or timings are given for the handover protocol or the local checking idea, and both are models checked in FDR, not code. The author lists proving the Bully algorithm and a distributed database protocol for all N as still-open challenges.
    • how much was read: most of it read
    • source; notes: The Challenges and Triumphs of CSP Based Formal Verification (2024)
    • record id: csp-retrospective-2024
  • Datadog Courier (2024)
    • title: How We Use Formal Modeling, Lightweight Simulations, and Chaos Testing to Design Reliable Distributed Systems (Datadog Courier)
    • what: Datadog modeled its Courier message queue in TLA+. It checked a liveness property named NoLostMsgs with TLC under weak fairness (an assumption that a continuously enabled step eventually runs). After a sequencer was added, TLC found a counterexample, and the design changed.
    • number: TLC scanned 5,515,710 distinct states with no violation in the first model
    • limits: It is a vendor post and not peer reviewed. The models do not validate the implementation.
    • how much was read: most of it read
    • source
    • record id: datadog-courier-2024
  • Datadog Courier blog (2024)
    • title: How we use formal modeling, lightweight simulations, and chaos testing to design reliable distributed systems
    • what: Datadog describes using TLA+ and TLC to model Courier, finding a message-loss counterexample after a design change, then combining model checking with simulation and chaos testing; it explicitly notes model/implementation mismatch limits.
    • limits: Already present in the local database; this pass reread and verified the page, so it is not newly added.
    • how much was read: most of it read
    • source
    • record id: datadog-courier-blog-2024
  • Distributed Locking as a Data Type (2024)
    • what: A work-in-progress report that writes two mutual-exclusion protocols (token passing and majority voting) as replicated data types in Scala. A replicated data type is a value with a merge function so replicas converge without messages. It gives an informal induction proof for the token protocol.
    • number: two protocols, token and voting; a Raft-inspired protocol is mentioned as implemented
    • number: no experiments or proof-assistant proof
    • limits: Safety needs only message integrity and progress needs at-least-once delivery. The token protocol has no progress if the owner fails permanently; the voting protocol assumes a fixed set of voters. Verification inside the LoRe language is future work.
    • how much was read: most of it read
    • source; notes: Distributed Locking as a Data Type (2024)
    • record id: distributed-locking-as-a-2024
  • Formally Verifying the Safety of Pipelined Moonshot Consensus Protocol (2024)
    • what: # Formally Verifying the Safety of Pipelined Moonshot Consensus Protocol (authored by agents unless marked 🧑) M. Praveen, Raghavendra Ramesh and Isaac Doidge, arXiv:2403.16637v1, March2024; the PDF identifies FMBC2024 in its metadata. The authors report an IVy proof that honest validators’ committed chains are prefix-comparable for arbitrary network sizes under an abstract honest-quorum-intersection assumption. This is a safety verification of a high-level model, using190 reported invariants and23 monitors. Liveness is future work; cryptographic checking, executable implementation refinement and transaction validity are outside the demonstrated result (Q1,Q4,Q6,Q8,Q11). ## Reading and evidence scope Read all17PDFpages: sections1–7,30bibliography entries, AppendixA, the complete Figure1 protocol pseudocode, the unnumbered proof-dependency diagram, both tables and the appendix IVy listing spanning pages15–17. No numbered theorem/proof, evaluation plot or checklist appears. Individually inspected renders5,9,10,15,16,17 to verify the protocol, numerical table, proof diagram and appendix code. Complete extracted text was read for every page; visual scope is limited to those six renders. References were read as entries, not recursively followed. Fetched the paper-linked GitHub repository metadata and a complete nontruncated tree. Chose commit1eae7974044d6981b214aa231d4e1c7d6f1bc1b3, the most recent commit affecting suprabft before26March2024. Its date is8February2024. This is a documented historical-source selection, not proof that this exact commit produced every reported check. The current repository has later changes; the record does not substitute current HEAD for the paper-era source. Nine retained files have SHA256 and matching Git-blob identities. Read README, types.ivy, ubd_seq.ivy, network.ivy, moonshot.ivy, quorum_verification.ivy, check_all.sh and Isolates.txt whole. Read selected safety.ivy ranges1–140,703–875,1007–1115,1170–1195 and1230–1309, plus search hits for axioms/assumptions/isolates. This is not a whole1,309-line proof-file audit. Large IVySummary/IVyTrace logs, slides, backup/trial proof files and external tool-library modules were inventoried but not read. No author code, IVy model, checker or SMT solver was executed/imported; no model/checkpoint/serialized experiment data was loaded. ## Exact property and fault model Each validator maintains committed blocks and its latest committed block. Safety requires that for any two honest validators one committed blockchain is a prefix of the other. The model may allow one validator to lag arbitrarily far behind another; it need not require equal states at every instant. The retained full_safety definition makes three conditions explicit: the first tip equals or precedes the second; every block of the first set is in the second; and every extra block in the second descends from the first tip. The invariant requires this relation in either direction for honest participants (Q4,C8). The protocol explanation assumes n=3f+1 and quorums of2f+1, with at most f Byzantine validators. The mechanized abstraction does not prove a cardinality theorem with this arithmetic. It axiomatizes that every pair of quorums shares an honest member, and that an f+1 timeout group has an honest member. For the stated cardinalities, ordinary set counting justifies the honest intersection: two2f+1 subsets of3f+1 participants overlap in at least f+1, exceeding f faulty members. That arithmetic connection is reader reasoning, not a separate IVy run (Q2,Q5,C1). The paper motivates partially synchronous operation, but the safety network is asynchronous: messages may be lost, duplicated or reordered. Timers are Boolean expiration events that may occur nondeterministically. Neither eventual delivery nor a known time bound is needed for the stated prefix invariant; those abstractions cannot establish eventual commits or latency. The source explicitly says liveness would require fairness for timer execution and additional handling of directly received prepare quorums (Q5,Q6,C5). Byzantine validators can send arbitrary modeled messages under Byzantine identities, including impersonating other Byzantine validators. They cannot forge an honest identity. Digital signatures and hashes are abstracted: block identity replaces digest computation; global records of honest sent messages validate a certificate’s claimed members. These monitors are proof instrumentation, not a deployed trusted coordinator. Their faithful relationship to actual cryptographic validation remains an implementation/refinement obligation (Q5,Q6,C2,C3). ## Protocol cases Views have rotating leaders and three voting/proposal paths. A normal proposal extends the block certified in the preceding view. A fallback proposal carries a timeout certificate and extends the block whose included quorum certificate has the highest view. Optimistic proposals let the next leader propose a child immediately after voting, before receiving the current block’s certificate. Honest voting guards constrain prior optimistic/normal/fallback votes and timeouts; certificates aggregate votes of one type. An honest validator may vote at most twice in a view under the displayed rules (Q2,Q3). A validator advances with a quorum or timeout certificate, updates the locked highest-view certificate, and resets its timer. It commits a block when that block and its child are certified in adjacent views, then commits uncommitted ancestors. The one-block-per-network-hop and three-hop finalization claims describe the normal-path design in the cited protocol work; this verification paper supplies no throughput/latency experiment or implementation performance result (Q2,Q3). The source separates message receipt from processing. A normal proposal must be received from the current leader, contain a constructed block and appropriate certificate, satisfy timer/first-processing conditions and the vote predicate; it may process the certificate first and propose the next optimistic block. Timeout/fallback handlers require embedded certificates to have been processed, explicitly constraining the environment to perform those steps first. This is a modeling convention to retain in any source correspondence argument, rather than evidence that every implementation obeys the ordering (C4,C5). The eight whole source reads expose additional concrete abstractions. Fresh blocks are chosen from initially present unconstructed objects. Genesis has its own certificate and all participants in its quorum. The optimistic-last-block variable initially uses a separate unused block rather than the paper’s genesis digest; a comment calls this a proof-performance shortcut. Honest/block validity invariants are separate from the top safety invariant. These details are not silently normalized to the informal algorithm (C1,C3). ## How the proof is organized IVy generates initiation/preservation obligations for inductive invariants and asks Z3 to discharge them. Isolates expose selected supporting properties to control formula size and logical fragments. Passing one isolate while assuming dependencies is only part of a complete verification; those dependencies also need checking. The paper reports completing that process but this read does not replay it (Q5,Q7,Q8). The principal argument establishes that certified blocks proposed in later rounds descend from the directly committed block. This ordering concerns proposal rounds, not the time a delayed certificate is received. Additional invariants establish ancestry among each honest validator’s committed blocks, closure under committed ancestors, and ancestry comparability of different honest tips. These establish prefix comparability. The paper supplies a five-step informal proof outline and a dependency diagram, not the full text of all obligations. The retained source supplies the exact omitted blockchain_prefix formula (Q7,Q8,C8). The difficult descendant lemma uses induction over rounds. The paper says “The principle of induction is taken to be an axiom” (§4.3,p10). The source includes an explicit parameterized induction schema in quorum_after_ldc_descendant; related predecessor/successor results also use schemas. These are mathematical assumptions/rules requiring an intended natural-number interpretation, not automatically inferred from a bare arbitrary total order. The retained ubd_seq defines immediate successor using the absence of an intermediate element and supplies a nat implementation; no such implementation was executed or proved anew here (Q8,C1,C6,C13). Transitive closure is not directly definable in first-order logic. A monitor incrementally records ancestors when blocks acquire quorums; supporting invariants establish parent inclusion, transitivity, no divergent ancestors and recovery of the immediate-parent relation from ancestry. The commit update is in safety.ivy rather than simply the core moonshot module: commit_candidate requires local direct commit, descent from the current tip, processed-certificate conditions for ancestors, and maximal eligible round; its after-qc-processing monitor updates the committed set/tip. Thus the exact model being verified includes proof-file actions, not just moonshot.ivy alone (Q8,Q9,C7,C12). No contradiction or reachable fork was established by this read. Static source inspection is insufficient to certify every isolate dependency, axiom, abstraction or proof result. The paper’s categorical statements that verification conclusively rules out design/logic errors should be understood relative to this formal model, stated axioms, tool behavior and intended correspondence, rather than as a theorem about arbitrary implementations or all blockchain security properties (Q4,Q11). ## Reported evaluation and retained artifact Table1 reports338lines of Types,110Network,642Moonshot,165Quorum verification and1,309Safety, totaling2,564. These counts exactly match physical line counts of the five retained files at the selected historical pin. The printed ratio of program code to proof is approximately1:3; that partition is descriptive, since files also contain comments, data abstractions and monitors. The authors report190invariants and23monitors, but do not specify a counting convention. A simple line-prefix count finds188invariant declarations in safety.ivy and211across those five files, including other invariants; do not equate that lexical count with semantic proof obligations or silently replace the published number (Q7,C9). The reported effort is about140person-hours after the protocol specification stabilized,10%modeling and the remainder proofs. Fourteen modeling and126proof hours are reader arithmetic, not a time log. Earlier protocol revisions and proof/specification iterations are discussed but excluded from that clearly stated starting point. No verification wall-clock benchmark, hardware specification, exact IVy/Z3 version, variance, isolate runtime table or controlled cross-tool comparison appears (Q7,Q9,Q10). The README gives a full-file checking command; check_all.sh instead lists116individual isolate checker invocations separated by date commands. Static shell inspection finds no fail-fast option or aggregate-status check and a final date command. Therefore running the script can return success even if an earlier checker command fails. This is a wrapper-status limitation, not evidence that a particular historical obligation failed or that the README’s separate command masks failures. Isolates.txt lists an older basic_safety structure, so it is not used here as a certificate of current full_safety dependency coverage. Unread trace/summary logs are not evidence of successful complete checking in this record (C10,C11). The authors describe solver stalls, inlining nested subroutine calls, explicit intermediate facts and fine dependency selection. Their concrete ancestry example adds two intermediary ancestor facts so that transitivity becomes easy for Z3. These are useful proof-engineering observations without controlled ablations or measured universal speedups. The claimed lower effort than Coq and preference over TLA+/TLAPS are author experience/opinion, not a matched comparison of equivalent developments (Q1,Q9,Q10). ## Contribution to the requested topics This is a directly relevant parameterized Byzantine-consensus safety case study: abstract honest quorum intersection, asynchronous safety despite timer abstraction, certificate-authentication monitors, ancestry instrumentation, round induction and modular solver obligations. It reports human verification work rather than LLM agents. It has no Verus or verified Rust artifact and does not prove a TLA+ model. For agents writing specifications/proofs, the transfer is a reader proposal: preserve exactly which code and monitor actions define the model; separately check dependencies and axioms; expose small intermediate ancestry facts; retain failures from every checker invocation; and distinguish a proof of an abstract invariant from executable refinement, crypto correctness, liveness and application security. The190-invariant/140-hour development is a potential future study case, not evidence of an agent success rate or measured automation benefit.
    • limits: Honestquorumintersectionandinductionaxioms;unforgeablehonestidentities;Boolean-timer/asynchronoussafetyabstraction;globalcertificate/ancestry/commitmonitors;noimplementation/crypto/liveness/transactionvalidityproof;noauthorcodeexecution
    • how much was read: most of it read
    • source
    • record id: formally-verifying-the-safety-2024
  • IronSpec (2024)
    • title: IronSpec: Increasing the Reliability of Formal Specifications
    • what: Tests whether a Dafny specification matches what developers expect. It uses three methods: checks with unconstrained inputs and outputs, small proofs of cases that should or should not be allowed, and mutations of the specification.
    • number: 14 specifications including six real verified systems; ten spec bugs confirmed by authors
    • number: 70 small test proofs, 21 needed help averaging 1.7 added lines
    • number: 61 surviving mutations, 13 judged intended
    • number: human effort hours to days; DaisyNFS about one to two hours
    • limits: The checks expose suspicious differences. They do not show the spec perfectly matches intent. It gives no success rate for autonomous spec generation.
    • how much was read: most of it read
    • source; notes: Specification errors and auditing; notes: IronSpec
    • record id: ironspec-2024
  • Modelling the Raft Distributed Consensus Protocol in mCRL2 (2024)
    • what: # Whole read: Modelling the Raft Distributed Consensus Protocol in mCRL2 (authored by agents unless marked 🧑) Bora, Pham Duc Minh and Willemse, MARS 2024, EPTCS 399, pp. 7–20; DOI 10.4204/EPTCS.399.4; arXiv 2403.18916v1, submitted 27 March 2024. Read all 14 PDF pages, §§1–5, Figure 1, Table 1, acknowledgement and 14 references, in text and rendered pages. Also read the official MARS mCRL2 model, all nine property files, README and batch script statically. The downloaded paper matches the indexed PDF byte for byte. No author code, model checker, prover or solver was executed. Raw sources, hashes, scope and exact excerpts are retained separately. The paper contributes an action-based Raft model and modal ”-calculus formulas, with reported model-checking results for eight finite configurations. It does not establish unrestricted Raft correctness. More specifically, the authors write, “All main properties hold true for all configurations of Table 1; verification of each property takes roughly 2-3 times that of generating the state space” (§3, PDF p. 9 / printed p. 15; Q19). Static inspection also finds differences between the printed formulas, artifact formulas and model indexing. These narrow what a successful check can establish; they are not claimed reachable protocol counterexamples. ## Model and assumptions The model follows the TLA+ and LNT specifications and focuses on leader election and log replication: “Features such as cluster membership changes and log compaction have not been modelled” (§2, PDF p. 2 / printed p. 8; Q3). Node, Network and Client processes run in parallel; communicating actions and allow restrictions enforce synchronisation. Analysis requires a “fixed, concrete number of servers” (§2, PDF p. 3 / printed p. 9; Q4), rather than a proof quantified over all cluster sizes. One client sends a bounded sequence of unique natural command IDs, abstracting away command contents and application behavior (Q5). Client-to-cluster communication is synchronous; communication among servers is asynchronous through the network. The network holds a finite set of payloads, permits reordering and limits capacity (Q7). Thus two identical pending payloads collapse to one set element. Reliable mode supplies no scheduler fairness guarantee. Capacity can block sends; the broadcast admission guard uses the number of servers rather than the exact outgoing set size (Q47). These are model restrictions, not a general unbounded or duplicate-preserving network semantics. The scope description has a tension worth retaining. Section 2.1 says, “we do not analyse the Raft algorithm in the presence of message loss or duplication” (PDF p. 4 / printed p. 10; Q6). Table 1 nevertheless includes one lossy-and-crashing row, and §3 reports all main formulas true for every row (Q18–Q19). The model supplies an optional loss branch (Q8, Q47). The defensible reading is a primarily reliable model with one reported loss experiment; no duplication experiment is reported. Each server has role, term, log, commit index, vote state, replication indexes and a pending reply. Figure 1 adds a Crashed role to Follower/Candidate/Leader (Q9–Q10). Entries are Command(term, commandID), stored in zero-based mCRL2 lists; the authors explicitly warn that Raft’s original indexing is one-based (Q11). Only leaders accept client commands. Elections and heartbeats use nondeterministic actions; “we cannot analyse real-time requirements, nor the real-time performance of the algorithm” (§2.2, PDF p. 6 / printed p. 12; Q12). There is no sampling of randomized timeout intervals or elapsed-time state. A candidate votes for itself and sends vote requests to other nodes not already in its voter set (Q13). Stale RPCs are discarded. A received request computes and stores a reply before the later send, allowing a crash between the state update and reply transmission (Q14). The artifact’s resume transition preserves currentTerm, log and votedFor, but resets commitIndex, voterLog, nextIndex, matchIndex and the pending reply, and returns to Follower (Q46). Reply computation itself is atomic: the authors acknowledge it “does not accurately reflect real-world scenarios where the computation of a reply would involve multiple steps” (§5, PDF p. 13 / printed p. 19; Q35). Leaders send one log entry at a time; the model uses nextIndex backtracking to find a matching prefix (Q15). Majority replication commits only a current-term entry directly; earlier entries are committed indirectly with it (Q16). This is a protocol model without a refinement proof connecting a Rust implementation, application state machine or storage system to these transitions. ## What the properties check The action logic cannot inspect process parameters directly. The model therefore adds self-loop actions exposeLeader, exposeLogLeader and exposeLog (Q19, Q46). Safety formulas compare exposed states across arbitrary later execution, rather than merely reading two process parameters in one state. Election Safety. The printed formula forbids a different node from ever later exposing leadership in the same term (Q20); the artifact agrees (Q52). An additional existential formula asks whether a leader can be exposed at all; another asks whether two different node IDs can eventually expose leadership (Q21). The latter is reported true only with at least two terms. These are witness-existence checks, not eventual election on every execution. The least-fixed-point formula counts possible leader announcements whose ID differs from the most recently stored ID, starting with id=1 and count=0 (Q22, Q53). It does not compare the associated terms or demand globally distinct IDs; a later reuse of an earlier ID can count. It is therefore more precise to describe its actual counter than to call it a proof of MaxTerm distinct leaders or guaranteed succession. Log Matching. The intended statement is that the same index and term imply identical prefixes through that index. The paper’s guard instead tests complete entry equality, log1.index == log2.index, which is a stronger antecedent and makes the standalone requirement weaker (Q23). The artifact repairs this to term(log1.index) == term(log2.index) and checks both list bounds (Q49). Both versions compare slice(log,1,index+1). The supplied slice helper begins at zero and excludes its finishing index (Q42). It therefore omits position 0, the first actual entry; initial logs contain no dummy element (Q48). Reader-created one-entry logs [Command(1,1)] and [Command(1,2)] have matching terms at position 0, but both compared slices are empty. This separates the intended first-entry equality requirement from the artifact formula. It does not establish that these two logs coexist in a reachable model state. Leader Completeness. After advanceCommitIndex(old,new,term,log), the formula asks that selected entries occur somewhere in every later-term leader’s exposed log (Q24–Q25, Q51). The membership consequent is weaker than retaining each entry at its original index. There is also an indexing discrepancy: it selects log1.index for old < index <= new, while the model’s getTerm translates Raft index to list position index-1 (Q41). With a singleton log and new=1, the formula selects zero-based position 1 rather than 0. No semantic result for out-of-bounds list selection, checker failure or reachable counterexample is asserted here. For commits in the sole elected term of a one-term configuration, there is no later leader term to test; the auxiliary leader/commit existence checks do not make every main formula nonvacuous. The event itself has a separate static inconsistency. On the successful AppendEntriesResponse branch, advanceCommitIndex computes its new index from the old matchIndex array, whereas the following Node transition computes commitIndex after incorporating the new acknowledgement (Q45). A local valuation with one entry, old matchIndex=[0,0,0] and an acknowledgement of entry 1 from another server yields event new index 0 but state commit index 1 using the supplied count helper (Q43–Q45). Reachability of that valuation was not established. The source expression mismatch is sufficient reason not to equate the event range automatically with all newly committed entries. State Machine Safety. The intended statement forbids two nodes applying different entries at the same committed index. Paper and artifact compare slice(log1,1,commitIndex1) and the corresponding slice of a later other node with commitIndex2 >= commitIndex1 > 0 (Q26, Q50). Under the artifact helper, position 0 is excluded. For commitIndex1=1 both slices are empty, independent of the first entries. Thus a successful check of this formula alone cannot establish agreement on the first committed entry. Again, this is formula coverage established by symbolic values, not a reachable protocol failure. An existential companion asks whether two different nodes can expose positive commit indexes in sequence, the later one at least as large (Q27). It does not repair prefix coverage or prove every request eventually commits. Append Entries is omitted as a separate checked property because the authors consider it immediate from the modeled leader operations (Q19). ## Reported evaluation and concrete cases The authors used manual interactive simulation and safety formulas throughout development to find model bugs (Q19). Table 1 gives eight configurations, all with three nodes and capacity three. The following preserves the reported rounded sizes and approximate generation times; every row is retained in numeric-evidence.json (Q18, §2.2, PDF p. 8 / printed p. 14): - 2 commands, 1 term, reliable, no crashes: 2.14×10^5 states, about 1 minute - 1 command, 2 terms, reliable, no crashes: 1.17×10^6 states, about 2 minutes - 1 command, 3 terms, reliable, no crashes: 1.32×10^7 states, about 13 minutes - 2 commands, 1 term, reliable, crashes: 1.79×10^7 states, about 5 minutes - 2 commands, 2 terms, reliable, no crashes: 2.25×10^7 states, about 19 minutes - 2 commands, 1 term, lossy, crashes: 5.97×10^7 states, about 105 minutes - 1 command, 2 terms, reliable, crashes: 1.48×10^8 states, about 24 minutes - 1 command, 3 terms, reliable, crashes: 2.38×10^9 states, about 820 minutes The first seven times use a 2017 Macbook Pro with 16GB; the last uses an unspecified compute server and is explicitly “not directly comparable to the other runtimes reported” (Table 1; Q18). No repetitions, error bars, exact CPU, per-formula times or implementation latency/throughput are supplied. The paper reports roughly 2–3× generation time for each main property using symbolic verification (Q19, technique reference Q38). The base configuration compresses by almost factor 5 under strong bisimilarity; no exact reduced size is given (Q17). The artifact README names mCRL2 release 202307.1 and gives explicit and symbolic commands (Q56). Its default model has five servers, two requests, one term, capacity five, no loss/crashes, and PRIORITISE=false (Q40). Seven individually guarded Node instances support the small configured sizes (Q48). The batch script substitutes three servers/capacity three, requests 1 or 2, terms 1–3, and both Boolean loss/crash settings, for 24 combinations (Q57). It includes all .mcf files, including timeout/client-command checks (Q54–Q55); neither the script nor their inclusion is a saved result log. Do not infer that every batch combination or every extra formula was successfully checked. The official archive contains source and instructions, not experiment output or an identified experiment commit. MAJORITY is ceil(NumberOfServers/2) in the artifact (Q40). That is a strict majority for the odd sizes three and five here, but only half for even sizes. No arbitrary-size correctness claim should be inferred from the configurable constant. Section 4 illustrates how modeling style changes generated state count. A Boolean process with conditionals after the action yields 3 states/6 transitions; moving the choice before the action yields 1 state/2 transitions, strongly bisimilar to the first (Q29–Q30). The tool can then remove an unused process parameter. The example supports a concrete state-generation lesson; it is not a measured uniform threefold Raft reduction. The claim that an early inexperienced model was “orders of magnitude larger than needed” is an author observation without a controlled Raft benchmark (Q29). ## Relation to the research topic The direct contribution is a finite distributed-protocol model and action-logic encodings of selected Raft requirements, with bounded symbolic checking and concrete resource measurements. The authors describe the modal formalizations as apparently new while acknowledging the prior TLA+, LNT and Verdi work (Q2, Q33, Q39). This is useful evidence about specification design, state exposure, state-space growth, crash abstraction and model/property correspondence. The TLA+ comparison is specific. The authors say TLA+ answers stale requests but drops stale responses; their model follows LNT in discarding both. They follow TLA+ when bounding transmitted commit information, and add reboot behavior they say is absent from the LNT model (Q31). These are attributed source discussions, not an independent audit of all upstream artifacts. Section 4’s view that imperative LNT is more appealing to average engineers is an author opinion, not a user study (Q32). For evaluating LLM agents writing specifications or proofs, the useful checks are reader inferences: validate a formula against its helper definitions, include first/last-index examples, inspect whether instrumentation exposes the actual state transition, distinguish term equality from entry equality, and separate existential witnesses from inevitable progress. This paper supplies concrete reasons these checks matter, but it contains no LLM-agent, Verus, verified-Rust or implementation-refinement evaluation. The liveness boundary is explicit: “Stronger liveness requirements, asserting that always inevitably a leader must be elected, are simply not true in our model” (§5, PDF p. 13 / printed p. 19; Q34), owing to crashes/loss and bounded terms. More complex configurations, stronger liveness, finer reply computation and real-time verification remain future work (Q33–Q36). Successful bounded checks therefore support the specified finite model and literal formulas, subject to the correspondence issues above. They do not independently establish the stronger prose requirements. ## Evidence and review quotes.json contains 57 literal excerpts with file, section, PDF/printed page where applicable, line ranges and character offsets. combined.quote-source.txt contains every excerpt for database validation. source-files.json retains raw hashes; source-scope.json distinguishes whole-paper and static artifact coverage. numeric-evidence.json preserves all table rows, and static-witnesses.json records reader-created separating values. reader-diagnostics.json separates source claims from reader findings. REVIEW.md and validation-final.json track consultation, independent review and mechanical checks.
    • limits: Fixed finite cluster,client commands,terms and finite-set network capacity; one synchronous client and asynchronous interserver RPC; no membership changes/log compaction; nondeterministic untimed timeouts,atomic reply computation,optional crashes/reboot/loss. Eight reported three-node configurations. No duplication/multiplicity or fairness guarantee. Static indexing/formula/event mismatches qualify property coverage.
    • how much was read: most of it read
    • source
    • record id: modelling-the-raft-distributed-2024
  • MoSt (2024)
    • title: Modeling and Verification of Natural Language Requirements based on States and Modes
    • what: Engineers write requirements in a controlled language that names states, modes and transitions. A tool generates NuSMV models and automatically checks that each state is reachable. It reports results at the requirement IDs.
    • number: car: 5 states, 2 modes, 37 requirements, 88 NuSMV lines
    • number: washing machine: 15 states, 5 modes, 64 requirements, 213 NuSMV lines
    • number: 14 injected errors all detected
    • number: check times 0.003/0.042/0.032 s (car) and 0.005/13.371/13.467 s (washer)
    • limits: Humans must first identify the states, modes and properties. Extracting them from free prose is future work. It has two authored examples only. It has no code proof.
    • how much was read: most of it read
    • source; notes: MoSt: humans structure requirements before automatic model checking; notes: MoSt: humans structure requirements before automatic model checking
    • record id: most-2024
  • mypyvy repository (2024)
    • title: mypyvy: A Research Platform for Verification of Transition Systems in First-Order Logic.
    • what: mypyvy is a symbolic transition-system language inspired by Ivy. Its README documents inductive invariant checking and inference and gives a lock-server example.
    • number: 43 top-level examples, 83 more under misc and fbii
    • number: examples/misc/pd at the inspected checkout has 39 .pyv files covering cache, consensus, lock service, ring election, sharded KV, TLB and Paxos variants
    • limits: The README gives setup and examples, not benchmark results.
    • how much was read: most of it read
    • source
    • record id: mypyvy-repository-2024
  • RTLola UAV Monitoring (2024)
    • title: Monitoring Unmanned Aircraft: Specification, Integration, and Lessons-Learned.
    • what: Reports integration of RTLola-generated runtime monitors for electric unmanned aircraft across log analysis, hardware/software-in-the-loop testing and flight tests, with an abstraction decoupling stable specifications from environment-specific integration. Defines translation layers between system outputs and monitor inputs, validates event-source mappings, and presents flight-phase detection, detect-and-avoid, geofence, sensor/system checks and other representative specifications. The monitor was integrated into development environments and tested in a flight with feedback to ground control.
    • number: Three organizations contribute authors: CISPA, Volocopter and DLR
    • number: A large case study covers representative specifications across multiple integration environments
    • number: A final test flight reports monitor feedback to the remote pilot
    • number: No quantitative accuracy/runtime benchmark table is reported
    • limits: Some specifications are unpublished because they require complete system knowledge. The monitoring approach checks observed streams and integration assumptions; external components must conform to their specifications. The paper reports a large case study and test flight rather than controlled detection-accuracy or runtime benchmarks.
    • how much was read: most of it read
    • source
    • record id: rtlola-uav-monitoring-2024
  • Synthetic Programming Elicitation for Text-to-Code in Very Low-Resource Programming and Formal Languages (2024)
    • what: SPEAC makes an LLM generate a familiar intermediate language, repairs that output with compiler checks and weighted MAX-SMT, then translates it into a language poorly represented in training data. Eudoxus instantiates this with a subset of Python that describes UCLID5 transition systems. It prunes unsupported syntax, replaces inconsistent syntax-tree nodes with holes, infers repairs from a satisfying model and asks the LLM to fill remaining holes. The evaluation measures compiler acceptance and a single author’s manual semantic scores on 33 textbook tasks. Preserves how the intermediate language was manually designed, exact pruning/constraint/repair contracts and minimality conditions, the traffic-light input ownership mistake, type and timer concerns, every result-table cell and denominator, three dataset roles, baseline and call settings, manual scoring, timing components and limits of the semantic claim. Distinguishes satisfying static constraints from preserving intended behavior or proving the generated transition system.
    • limits: §3–§5: Requires a target language T, familiar parent P, child subset C and compiler f:C→T. Here T is UCLID5, P Python and C an abstract Module subclass with declaration/init/next methods. The language design and syntax-directed translator are supplied by people; the paper does not prove compiler semantic preservation or automatically derive a correct modeling language. §5.1: Synthetic elicitation is a manual lightweight grounded-theory analysis of LLM outputs, not a human-subject study. People label output fragments, group codes into concepts/categories and design C. The object-oriented category is chosen for ease of translation; no experiment establishes universal LLM naturalness or superiority over every alternative child language. §5.1, p.6: GPT-3.5-turbo-0125 and GPT-4-turbo-2024-04-09 each generate ten samples on each of 33 curated regression tasks: 660 direct-UCLID5 attempts, none parses. This is a result for those models/tasks, not a universal inability theorem. Imaginary FormalVerificationLibrary prompts elicit from-scratch Z3, procedural API and object-oriented subclass styles. §5.2/Figure 4: Initial prompt specifies parent, task, unique code block and child description, ending with an affirmative assistant prefix. Repair prompt asks to replace every ?? and repeats the task. The templates are partial; the PDF does not include every concrete benchmark prompt or the complete child grammar. §5.3: Error-tolerant parsing first builds a parent-language AST, then removes constructs outside C. This initial pruning may lose program intent. Static checks are encoded as soft clauses per node; MAX-SMT keeps a satisfiable weighted subset and rejected clauses identify nodes to replace with holes. Hard clauses and algebraic data types constrain legal structure. §5.3, p.7: Minimum node-edit guarantee is conditional on uniform weights and exactly one clause per node. Actual depth-proportional weights favor edits near leaves and explicitly break syntactic minimality guarantees. Largest consistent subtree therefore does not imply globally fewest edits in the implementation or smallest semantic change. §5.4: A satisfying model can infer a hole’s type, e.g. integer from integer-literal assignment; unresolved holes return to the LLM. Satisfying static constraints establishes a well-formed intermediate program, not equivalence to its original candidate, natural-language task satisfaction or a verified safety/liveness property. §3/Figure 1: Compiler-accepted traffic-light output declares pedestrian with var and initializes it false, although the task requires a nondeterministic input from another subsystem. Authors explicitly identify var→input as a semantic correction. Inference for distributed modeling: changing an environment input into locally controlled state can remove executions and make a property misleadingly easy to satisfy. Figure 1 lines 13–15 and Figure 5: The shown state-zero branch resets count to zero immediately before checking count<60 and incrementing it. Under the sequential step semantics suggested by the excerpt, that prevents this branch reaching 60. This is an apparent concern in a partial excerpt, not a confirmed full-model counterexample; the complete generated model and execution were not inspected. Authors discuss the pedestrian mistake, not this timer concern. Figures 5–6: Repairs replace BitVector declarations with int to match integer literal use, and replace Boolean()/False values in declarations with bool. Changing a bounded bitvector to integer changes wraparound/range behavior; static consistency alone does not preserve a bounded-state interpretation. Final snippets also show declarations/init separately and contain ellipses. §3/Figure 5: Figure 5 caption identifies (a) initial output and (b) repair; overview prose reverses these references. Figure 6 likewise contains partial outputs. Preserve the caption/code reading rather than treating the displayed snippets as a complete executable proof artifact. §6: Python implementation uses tree-sitter and Z3 MAX-SMT; local solver machine is a 2.3 GHz quad-core Intel Core i7 with 32 GB RAM, LLMs through OpenAI Python API. Repository is https://github.com/FedericoAureliano/eudoxus. This read covers the PDF, not repository code or a reproduced run. §6/Table 1: Text says allow repair loop five times; caption says limited to five LLM calls per benchmark. Self-repair baseline uses five iterations starting from zero-shot. Exact initial-call versus repair-count convention is not reconciled in the PDF; use the caption’s reported cap without silently adding an initial sixth call. §6: Three datasets have distinct roles: 33 curated developer regression tests with hand-written descriptions for language design; 317 repository regression tests self-summarized by the LLM for fine-tuning; 33 textbook exercises/examples for end-to-end evaluation. Textbooks are Baier/Katoen 2008, Lee/Seshia 2016 and Huth/Ryan 2004. No explicit split-overlap/contamination audit is given. §6: Fine-tunes GPT3t for 284 steps with learning-rate multiplier .16; no GPT4t fine-tune is reported. Baselines include one/three examples, with/without chain of thought, each on two models; two compiler-feedback self-repair variants; and fine-tuning. That is eleven baseline variants plus two Eudoxus variants, thirteen Table 1 rows; prose saying all eleven approaches is a counting slip. Abstract/§6: Abstract mentions retrieval baselines, but the specified baseline is repository few-shot prompting; no operational retrieval pipeline, retriever-quality measurement or retrieval ablation is described. Do not infer a separate implemented RAG system from that phrase. §6.1: Parse is shorthand for passing all compiler checks, including static typing, rather than grammar alone. Semantic assessment is one author’s manual reasoning plus hand-written specifications, performed only for compiled outputs. Scores run from 1 entirely wrong to 5 fully correct; ≄4 means authors believe useful, allowing minor errors. This is not an independently machine-checked end-to-end correctness result. Table 1: GPT3t Eudoxus parses 28/33=84.8%; GPT4t 24/33=72.7%. Combined 52/66=78.8% explains approximately 78% prose. Fine-tuning Table 1 is 2/33=6.1%, inconsistent with introduction 9.1%; preserve the discrepancy. Best GPT4t few-shot parses 4/33=12.1%. Percentages here are derived from printed counts. Table 1: Fully correct score-5 outputs are GPT4t 11/33 and GPT3t 9/33, not 24/33 or 28/33. Useful score≄4 outputs are 19/33 and 14/33 respectively. These derived unconditional denominators differ from the table’s conditional semantic denominators of 24 and 28 compiled outputs. §6.1: Across both Eudoxus variants, 30/33 unique tasks have at least one compiled output; across all eleven baseline variants, only 6/33 do. Eudoxus has 33/52 compiled outputs scoring ≄4, covering 24 unique tasks. Four unique baseline-useful tasks are also useful under Eudoxus. These unions are not a single model’s success rate or 33 verified specifications. §6.1: Four benchmarks hit iteration cap and three suffer implementation syntax/output-extraction/printing bugs. Their scope across model variants is unclear: the two table rows together have fourteen non-compiling outputs. Do not assign the seven reported cases independently to both models or invent an overlap explanation. §6.1, p.10: Reported GPT3t mean repair time .9 s (SD .6), LLM time 7.2 s (SD 4.6); GPT4t repair 1.8 s (SD 2.0), LLM 35.1 s (SD 24.7). These components support that LLM calls dominate reported local repair time. They are not total project compute, API dollars, token counts or a precisely specified aggregate wall-clock distribution. §6.1–§6.2: Authors explicitly caution that few baseline outputs compile, making conclusions about semantic performance difficult. No ablation separates child-language design, pruning, model-based repairs and repeated LLM calls; no broad budget-matched repeated-sampling comparison is reported. §6.2/Checklist: Only one target language, two LLMs and one semantic rater. No inter-rater agreement, semantic-score confidence intervals or statistical-significance claim; checklist item 7 explicitly calls this a case study. Generalization to other languages/models remains open. Checklist items 3–8: No theoretical results claimed. Code/data are said to be in supplemental material/GitHub; not executed here. Checklist says temperature settings are reported, but no numerical temperature is supplied in the PDF’s experimental description. Solver/compiler versions, exact seeds, repeated-run counts and solver timeouts are not disclosed there. Checklist items 10–15: Broader impacts answer No because work targets compiler checks; existing UCLID5 license stated as 3-clause BSD, textbook examples cited, new code/documentation claimed public. Human-subject and IRB questions marked NA. These are disclosure statements, not independent license or artifact verification. Whole paper: No generated distributed protocol, Verus/verified Rust proof, TLA+ specification, termination argument, concurrency refinement proof or validated natural-language specification oracle is evaluated. Formal tools repair syntax/types; UCLID5’s verification capabilities do not by themselves make generated models faithful to the task.
    • how much was read: most of it read
    • record id: synthetic-programming-elicitation-for-2024
  • TLA+ model-checking education (2024)
    • title: WIP: An Engaging Undergraduate Intro to Model Checking in Software Engineering Using TLA+
    • what: Describes an undergraduate/graduate teaching approach that introduces TLA+ and TLC through puzzles, a microwave controller, concurrency, bounded counters, and buffers. Students progressively confront safety, liveness, deadlock, and thread-safety failures. Analyzes model-checking courses, supplies reproducible examples and open-source modules, and uses successive counterexamples to motivate stronger requirements. The microwave case distinguishes safety (door/radiation) from liveness (eventual shutoff), while bounded buffers and counters introduce concurrency.
    • number: 84% of students reported a positive experience (§Abstract)
    • number: FMEDB analysis covered 34 model-checking courses out of 88 total (§I)
    • number: Preliminary survey covered 32 recent courses (§II)
    • number: No controlled learning-outcome comparison reported
    • limits: Findings are preliminary, based on one institution/course and anonymous student input; the paper explicitly calls the work in progress and plans longitudinal/multi-institution evaluation. Educational engagement does not measure professional verification competence.
    • how much was read: most of it read
    • record id: tla-model-checking-education-2024
  • TLA+ trace validation (2024)
    • title: Validating Traces of Distributed Programs Against TLA+ Specifications
    • what: Presents an API and TLC-based constrained model-checking workflow that records selected specification-variable updates from Java executions and checks whether the partial trace can be completed to a behavior of a TLA+ specification. The framework traces only chosen variables/events, leaving omitted values existentially open for TLC to reconstruct. It handles stuttering steps and implementation transitions that combine multiple TLA+ actions, and uses shortest BFS counterexamples or constrained DFS for speed. Case studies include Two-Phase Commit, snapshot-isolation key-value store, EWD998 termination detection, two Raft implementations and Microsoft CCF; trace validation found mismatches and exposed a CCF safety bug that became regression tests.
    • number: Counter implementation bug detected in less than one minute with event-only trace for 16 RMs
    • number: Two-Phase Commit 16 RMs event-only trace explores ∞/557k states (BFS/DFS table)
    • number: Key-value 12-agent, 20-key/40-value event-only trace reaches ∞ states at 1-hour timeout
    • number: Five distributed-program case studies all yielded specification/implementation discrepancies
    • limits: Verdicts depend on instrumentation points, trace granularity and the high-level specification. Too-imprecise logs can admit erroneous traces because TLC fills unconstrained values; too much logging causes state explosion. TLC explores finite bounded models and can return no counterexample for an invalid trace when the searched diameter is insufficient. The method detects conformance discrepancies, not a proof that all executions of the implementation satisfy the specification.
    • how much was read: most of it read
    • source; notes: P08. Validating Traces of Distributed Programs Against TLA+ Specificat
    • record id: tla-trace-validation-2024
  • Using Dynamically Layered Definite Releases for Verifying the RefFS File System (2024)
    • what: The RefFS project page links a separate 124-page draft, Progress of Concurrent Objects with Dynamic Dependencies, authored by Mo Zou. Its PDF metadata dates it May24,2024; the project says “A separate paper” illustrates MoLi’s metatheory (P1). This is a complete fresh reading of that PODD paper, not an appendix of the OSDI paper and not a new reading of the RefFS implementation. The original RefFS main-paper account remains inherited from formal509. Whether this precise draft proves every rule of the released MoLi framework is not established by the link alone. PODD makes a thread’s progress depend on definite actions, obligations that their owning threads must fulfill once enabled. Actions have state-dependent layers, and dependencies must preserve strict relative order even when numeric layers change. Layers have a total order, not necessarily a well-founded one. Finite dependency sets and decreasing local/stack metrics supply the termination argument. The LIVE-FRM rule extends action/layer context while preserving old ordering, so an acquisition proof can be reused without expanding every nested wait chain. Tokens account for unblocked loop progress and finitely many levels of delaying interference. Theorem4.2 states linearizability and deadlock-freedom; starvation-freedom additionally requires rely and guarantee actions at level0 (S12,S14,S15). AppendixA supplies the fuller resource/ownership logic, fences, rules and ideal shared-memory semantics. AppendixB first gives judgment simulations with finite-height while stacks: arbitrary-length lexicographic lists would not be well-founded (S31). B.3 expands new while/live-frame cases. B.4 maps these to a common simulation, directly for starvation-freedom and through a lock plus nondeterministically decreasing finite-wait wrapper for deadlock-freedom (S45,S48). B.5 combines thread simulations using finite active-thread dependency sets, scheduler rounds and a lexicographic metric. LemmasB.22–B.30 connect coinductive fair traces to refinement (S54,S57,S58,S66,S69). B.6 defines progress over complete fair traces, permitting abort alternatives, and uses three most-general clients to relate finite refinement to linearizability and fair refinement to linearizability plus starvation/deadlock freedom. The deadlock equivalence wraps the atomic specification; it must not be replaced by the stronger starvation refinement (S72,S74). AppendixC provides all printed proof outlines for nested TAS/ticket locks, ticket-lock coupling lists, optimistic/lazy TAS lists, and two-list transfers. Ticket queues support starvation-freedom; unfair TAS permits only the weaker deadlock-freedom claim. Lists use local lock obligations, node order and finite traversal metrics. Optimistic/lazy cases retain removed nodes in ghost garbage, not a proved memory-reclamation scheme. Lazy contain is explicitly omitted. Transfers use one mutex to serialize moves, list levels0/1/2 and lexicographic (listlevel,distance-to-tail) layers; their add/remove proofs are referred to earlier lists. The two-list move is a useful dynamic-dependency example, rather than a distributed network/crash model (S87,S90,S94,S102,S109,S116,S122,S124). Evaluation consists of paper proofs and worked examples; no numerical benchmark, proof-time table or replayed mechanization is supplied here. Section6 explicitly makes mechanization and automation future work (S20). Section5.1 admits that common rely conditions and frame stability can prevent reuse across objects (S17). Assumptions include fair scheduling, an arbitrary fixed finite number of threads, ideal atomic memory actions, safe total abstract methods and the presented non-nested method-call language. No bounded response-time, weak-memory, crash/recovery or implementation-to-binary theorem follows from this reading. Reader deductions from the literal listings must be kept separate from intended theorems. Figure40’s inner ticket loop never increments o; Figure55’s elems retains marked values and discards unmarked ones; Figure62’s sequential MOVE removes a head before reading the new head. Details and elementary counterexamples are in reader_diagnostics.json, with exact page anchors. These are printed-source defects, not findings about unseen code or a global refutation of PODD. The page also has draft-level omissions: a duplicated strict-comparison branch in the proof on p57, an apparent dependency-set type slip in DefinitionB.12, and an unresolved Fig.?? reference plus omitted scheduler semantics on p58. Underlines/fonts were visually checked before identifying these issues. Relevance to the requested database is manual liveness proof structure and evaluation of specification/proof agents: track actual fairness and progress strength, stable dependency ordering, finite metrics, abstract-method contracts, omitted cases and intended versus literal specifications. These are reader uses of a concurrency result. This paper does not evaluate Verus, Rust, TLA+, LLM agents or distributed consensus. RefFS/Coq performance and proof counts remain attributed to the inherited OSDI paper, rather than this draft. Records exact WHILE/OBJECT obligations, ticket and abstract-lock metric differences, dynamic-layer/TDep construction, VFS bug cycle and source typo, refcount ownership protocol, non-atomic operation abstraction, conditional theorem and unmechanized metatheory, survey denominators, all LOC cells, workloads, normalized performance limits and graph estimates. Separates checked RefFS proofs from trusted C/runtime/lock/allocator and protocol-only VFS reasoning.
    • limits: Fresh source: all124pages, every LF line and all31 rendered contact sheets read; larger renders48,51,54,57–59,66,68–69,96,111,118 inspected. Original21page RefFS main reading inherited from formal509. Separate PODD draft is not a same-title appendix or proof-assistant replay. S12,S15,S72,S74: fair scheduling and arbitrary fixed finite thread count; linearizability plus deadlock-freedom generally, starvation-freedom only under level0 rely/guarantee restriction. Abort alternatives in progress definitions do not establish memory safety by themselves. S10,S22,S23,S27: ideal shared-memory language, primitive atomic operations and specified safe/total abstract methods; presented language excludes nested method calls. No weak-memory, compiled implementation, network/crash/recovery or bounded response-time theorem. S12,S14,S31,S54,S66: total ordering of layers is distinct from well-founded local/stack metrics. Dynamic numeric ranks may change while actual strict dependency relations remain stable. Finite-height stack bound and finite active-thread sets are substantive premises. S17,S20: paper admits object-specific rely/frame obligations and leaves mechanization/automation for future work. Reading the linked draft does not identify its rules with every released MoLi implementation rule. S96,S111,S118: printed metric, lazy abstraction and MOVE inconsistencies require qualification before reuse as formal specifications; counterexamples are elementary reader deductions, without implementation inspection. S102,S109,S116: ghost garbage retention does not prove reclamation; contain and repeated add/remove proof cases are omitted/referred elsewhere. All supplied content was read; omitted derivations were not independently supplied. P1: directory depth ranks can tie. A uniquely determined numeric rank does not give a strict total order on directory identities. Strict ordering of actual lock dependencies needs its own invariant; this local wording issue alone does not refute the locking result.
    • how much was read: most of it read
    • source
    • record id: using-dynamically-layered-definite-2024
  • Bosch formal-verification explanation user study (2023)
    • title: A User Study for Evaluation of Formal Verification Results and their Explanation at Bosch
    • what: Studies Bosch automotive engineers’ challenges with formal notations, refinement inconsistencies, and model-checker output, then evaluates a counterexample-explanation approach. A 41-person survey and a one-group pretest/posttest with 13 formal-methods-aware engineers compare raw model-checker output against explanations for airbag and electronic-power-steering cases. The design separates RQ1/RQ2 survey constructs from RQ3 intervention measures (better/quicker understanding, confidence, and value), documents questionnaire scales and execution, and reports task-level correctness rather than only opinions. Six of 13 understood the airbag raw result; 12 of 13 preferred the explanation. For inconsistent specifications, 5 of 13 were fully/partly correct with raw output versus 9 of 13 with explanations. The discussion identifies integration with heterogeneous industrial toolchains as a practical barrier.
    • number: 41 survey participants
    • number: 13 experiment participants
    • number: 6/13 understood raw airbag result
    • number: 12/13 preferred explanations
    • limits: The study is exploratory and Bosch-specific. The survey uses snowball sampling and self-report Likert responses; the experiment has no control group, only 13 participants, different pre/post use-case difficulty, and possible testing/instrumentation effects. Data are not openly available because of Bosch sensitivity and engineer privacy. Generalization beyond Bosch automotive engineers is explicitly limited.
    • how much was read: most of it read
    • record id: bosch-formal-verification-explanation-user-study-2023
  • Cirisci Enea Mutluergil QTree (2023)
    • title: Quorum Tree Abstractions of Consensus Protocols
    • what: Introduces Quorum Tree (QTree), a sequential rooted-tree abstraction whose add and commit operations model quorum observations in consensus rounds. It proves safety of QTree and shows Paxos, HotStuff, PBFT, Raft, and Multi-Paxos refine one or more QTree instances via fixed linearization points. QTree nodes carry round, value, parent, and ADDED/GHOST/COMMITTED status. Predicates enforce unique rounds, parent links, trunk extension, and (for single-decree consensus) parent-value preservation. Theorem 1 characterizes correct successful invocation sequences using four checkable properties, including the key prohibition on committing a lower conflicting round after a higher branch is added. Paxos refinement marks PROPOSE as add and DECIDE as commit; safety follows from quorum intersection between vote and later join quorums. HotStuff uses valid PRECOMMIT and DECIDE certificates under 3f+1 Byzantine processes and 2f+1 quorums. PBFT maps each sequence number to an independent QTree. A table relates protocol phases to add/commit quorum phases and exposes quorum optimization opportunities.
    • number: QTree statuses ADDED/GHOST/COMMITTED
    • number: HotStuff N=3f+1 and quorum 2f+1
    • number: four invocation-sequence properties in Theorem 1
    • number: Paxos 2 phases; PBFT 3*; HotStuff 4 phases
    • limits: Refinement proofs assume round-based protocols with identifiable phases, fixed code locations as linearization points, honest processes for Paxos/Raft and cryptographically constrained Byzantine behavior for HotStuff/PBFT. Validity additionally requires client-value broadcast or equivalent checks. QTree is a safety abstraction; the authors do not establish liveness and note protocols without round decomposition (e.g., Texel) may not fit. Multi-decree protocols require independent QTree instances, and removing valueConstraint changes validity interpretation for state-machine replication.
    • how much was read: most of it read
    • record id: cirisci-enea-mutluergil-qtree-2023
  • Compositional Policy Learning in Stochastic Control Systems with Formal Guarantees (2023)
    • what: CLAPS learns policies and reach-avoid supermartingale certificates for edges of a DAG describing a SPECTRL task. A forward pass records the best certified product of edge probabilities and prunes prefixes below the global threshold. It extracts one certified path and uses a controller with memory of the current edge. Additive and multiplicative certificate formulations motivate a stronger model-relative probability bound using a Lipschitz/step-size delay before unsafe reachability. A stochastic nine-room example obtains a33.0% certified complete-path lower bound where direct policy/certificate learning times out. Records the exact certificate inequalities, stronger-bound conditions, full appendix proof arguments and printed gaps, verifier margin/numerical-expectation contract, stateful probability composition, restricted best-path completeness, every experiment/table value and the distinction between a33% lower bound and plotted successful trajectories. Identifies formula/translation/regularity discrepancies without assuming the uninspected implementation uses them.
    • limits: §3: Known dynamics xnext=f(x,π(x),ω), continuous state/action/noise spaces, fresh independent disturbances from a fixed known distribution at each step, Borel measurability, compact state space and continuous dynamics/policy. Model must map into X. Guarantees are for that stochastic model, every x0 in X0 and unbounded time to finite successful reachability; no bound on completion time or robustness to a changed disturbance law/model error. §3/p4/AppendixE/p23: Paper states continuous functions on compact domains are Lipschitz, which is false: sqrt(x) on[0,1] is a counterexample. The verifier actually requires valid finite Lipschitz constants for f,π,V; these must be additional assumptions or established for chosen neural networks/dynamics. Intro explicitly assumes Lipschitz dynamics. Compact X alone does not make unbounded U/W or their product compact. §4/Definition2: Additive RASM V continuous/nonnegative everywhere, V≀1 oninitials, V≄λ>1 onunsafe, and E[V(next)]≀V−Δ for all nontarget states withV≀λ,Δ>0. Stopping at target or certificate threshold distinguishes reachability from safety alone. A checked strict expected drift is essential; finite sampled decrease loss alone is not proof. §4/Definition3: Multiplicative RASM also requires V≄Ύ>0 outside target and E[V(next)]≀γV for nontargetV≀λ,0<Îł<1. Theorem1 converts additiveΔ toÎł=1−Δ/λ,ÎŽ=min(Δ,λ), and multiplicativeÎł,ÎŽ toΔ=(1−γ)ÎŽ. Proof uses nonnegativity to boundV≄Δ where active and V>λ elsewhere. FormulaÎł is admissible only withΔ<λ; degenerate vacuous active sets/Δ≄λ require choosing a smallerΔ. With a nonempty nontarget initial set,V≀1 enforcesΔ≀1<λ. §4/Theorem2: Assuming V isL1-Lipschitz with validLV and all transitions satisfy||x−f(x,π(x),ω)||1≀∆, N=floor((λ−1)/(LV∆)), lower bound reach-avoid≄1−γ^N/λ. ∆ andLV must bound all relevant states/noise, not just observations. N is a conservative lower bound on first threshold-crossing time; ceil would be the tight elementary distance bound, so floor is not literally the exact smallest time. IfN0, improvement vanishes; strictly tighter wording needsN>0. §4/AppendixD: Intended argument stops V at0 on target orλ on threshold exit, obtains nonnegative supermartingale and eventual stopping via positive additive drift, then scales byÎł^−time and applies maximal inequality. Printed p21 partition includes overlapping target/threshold indicators and a dropped indicator; equality after summing claimed disjoint sets is not literal as written. A proper disjoint partition and stopped process recover the standard first part. AppendixD/pp21–22: PrintedYt freezes atYt−1 on the threshold-crossing step, excluding the crossing valueλ/Îł^t. Thus its asserted equality between events supXt<λ and supÎł^tYt<λ does not follow: an exit can be hidden by freezing the pre-exit value. Printed second caseV=λ also misses overshootsV>λ. A repaired process that includes the crossing value then freezes has a standard supermartingale argument and supports the intended bound; printed proof requires correction, not treated as kernel-checked proof. §4/Table1: WithÎł.99,∆.1,LV5, theoremN=2(λ−1) for integerλ. Caption instead uses2λ. Forλ10/100 theorem values≈.916548624/.998633000, while table prints.91820/.99866, agreeing with the different exponent. λ1000 prints.99999 versus theorem≈.9999999999981. Both old1−1/λ values.9/.99/.999 preserved. Caption/theorem arithmetic discrepancy does not affect existence of a possible improved bound under corrected parameters. §4/Remark1: Pure-safety specialization sets targetempty andΔ0 orÎł1, outside the strict RASM parameter conditions used for finite eventual stopping. WithÎł1 factorÎł^N=1, displayed theorem yields no strict improvement over the old safety bound. Positive strict drift/positivity with empty target on compact globally closed dynamics cannot simply be assumed forever on a non-exiting path. Claimed generic stronger safety guarantee needs separate conditions/argument. §5/Algorithm1: Translate formula toDAG,topologicalorder;Prob[source]1; for each node learn only incoming edges from predecessors withProb≄globalp, maximizing certified edge probability by finite-precision binary search; update max ofproducts. This optimizes a single selected path lower bound, not the union probability of alternative paths or arbitrary adaptive strategies. Failed/pruned certificate bounds do not show no safe policy exists. §5/AppendixF: Product composition requires each edge certificate uniformly lower-bound success from every state in its source region, and the previous edge termination state lie there. At random switching times, Markov dynamics/independent fresh noise permit conditional lower bounds; no assumption of independent edge-success events is needed. Proof must use conditional probabilities, not multiply arbitrary marginal success probabilities. §5/pp8–9: Runtime global controller remembers the current edge and switches at its target; it need not be a stationary continuous function of physical x alone even though preliminaries writeπ:X→U continuous. Augment with finite mode for semantics. On a safety violation it retains current policy indefinitely. Reach-avoid only constrains until a successful target prefix; no post-goal invariance/stability guarantee. §5/Algorithm1: Binary search uses heuristic learner/verifier success with unspecified precision parameter. Existence of an optimal certificate monotonic in threshold does not imply a finite-time stochastic learner succeeds monotonically. Maximal probability is only a search heuristic/achieved certified bound; no completeness or global optimality. Termination/timeouts of inner learning needed operationally; conclusion expressly disclaims guaranteed policy return/tight bounds. AppendixA/Eq1: Grammar achieveb, φensuringb, sequentialφ1;φ2, disjunction. Infinite trajectory satisfaction means some finite prefix satisfies formula; ensuring predicate holds over the chosen finite prefix. Thus successful traces have finite witnesses even though no fixed uniform horizon is required. A failure can be witnessed by a finite unsafe prefix or by never reaching a target. SPECTRL semantics do not impose safety after the selected satisfying prefix. AppendixA/Theorem4: Claims all fixed-finite-horizon Finitary properties translate into SPECTRL by disjoining sequences of word predicates. Printed sequence p(w1);
;p(wH) is not grammar-valid without a formula wrapper, and eventual sequential achievement does not force positions to be consecutive or at the initial prefix. More fundamentally these untimed constructs are invariant under repeating identical consecutive states, while a next-step predicate can change under such repetition. Hence the claimed general fixed-prefix expressiveness reduction is not established as written; do not report it as proved. AppendixB/Theorem5: Claimed linear-vertex DAG-equivalence construction has missing/incorrect details: merging sequential child nodes uses second child source labelX0 and overwrites first target predicate; disjunction adds a source but does not describe merging final nodes or edge labels; strict time indicesi0<i1
 exclude zero-step achievement allowed by AppendixA. For example ifp holds only initially, achievep has an immediate witness but a single edge with strictly positive traversal time need not. Construction requires repair before literal equivalence follows; main paper cites prior construction separately. AppendixE/learner: Start withPPO, joint policy/certificate optimization, finite counterexample grids for initial/unsafe/decrease, softplus certificate output guarantees nonnegativity; initial max violation, unsafe max threshold gap, averaged empirical decrease residual plusτK, Lipschitz product-of-induced-L1-layer-norm regularization. Softplus networks can satisfy finite regularity bounds with valid layer norms, but zero empirical loss is insufficient for continuum expected drift. AppendixE/pp23–24: Verifier uses finite state meshτ and expected drift marginτK, K=LV*(Lf*(Lπ+1)+1), suppliedLf and computedLπ/LV. Interval arithmetic checks upperV≀1 on all cells intersecting initialset and lowerV≄λ on cells intersecting unsafe. Active cells must include all nontarget statesV≀λ. Soundness depends on valid bounds, correct cell coverage and certified expectations; grid dimension incurs scalability limits beyond shown2Dcase. AppendixE: Training decrease averages sampled noises, notationω1 ωN∌N inconsistently differs from disturbance lawd; Ξ/Îœ policy/certificate indices also swap. Verifier prints exactEω∌d but does not explain a sound integration/quadrature/interval expectation calculation in this PDF, referring to[68]. Training noise samples cannot stand in for a verified expectation without an error bound. λ starts1/(1−pâ€Č), decreases if needed for stronger bound, but unsafe loss still prints1/(1−p); relationp/globalpâ€Č/currentλ needs clarification. AppendixE/Theorem8: ÎŽ=min(min over grid(V−τK−E[Vnext]),λ),Îł1−ή/λ. Strict positive margin is guaranteed only on active checked grid points, yet printedminimum runs over allXtilde, including target/inactive states where decrease is not required. Need restrictminimum to checkedpoints; nonpositive inactive margin can destroyÎŽ>0. Ύλ also allowsÎł0 contrary to definitionγ∈(0,1); choose a strictly smaller positive margin in such cases. Proof of extension uses Lipschitz bound to transfer active grid slack to all active states. §6: Only one2D Stochastic Nine Rooms environment; no benchmark suite, scaling study, repeated-seed uncertainty, empirical success fractions, reward values, total training runtime or hardware/network/hyperparameter table. Four-hour timeout per reach-avoid task, no total task count/runtime inPDF. A single successful visualization does not validate the certified lower bound statistically. §6/Figure1/Table2: StateX[0,3]ÂČ,initial[.4,.6]ÂČ,target[2.4,2.6]ÂČ; nine subgoal boxes centered on room centers. Wall regions drawn, exactcoordinates/noise distribution parameters not listed. Printed dynamics clipping parentheses malformed; intendedactionclipping[-1,1] plus additive triangularnoise. f:X→X requires boundary/obstacle treatment not fully specified. Table1∆.1 is not established for the printed2D L1 displacement, which can be.2 with two unit clipped action components even before noise; action-domain restrictions could change this. Need valid dynamics/noise/step-size contract. §6/Table2: Selectedpath(0,0)→(0,1)→(2,1)→(2,2) has printed edge bounds.723*.615*.745=.331260525; table conservatively reports.330. Printed percentages may themselves be rounded. Direct jointlearning timesout, not proof that no direct controller/certificate exists; a composed controller is itself an overall controller with additionalmode. §6/Figure2: Gray edges failed verification under budget; blue certifiededges; chosenorange3edgepath avoidsbottomright route that could not be verified. Automated graph search outperforms this one natural decomposition in the example; no general evidence that it dominates all manual decompositions. Edge-local obstacle labels must cover all global unsafe regions reachable before subgoal, or extra domain restriction is needed to infer globalwallavoidance. §7: Applies toSPECTRL task language, not allLTL. Probabilistic reach-avoid has both eventual progress and avoidance but no distributed scheduler/fault/network model. Paper proves mathematical certificate/composition statements with noted printed issues; no machine-checked proof, proofkernel audit, Rust/Verus/TLA+ implementationverification or LLMagentexperiment. Artifact URL supplied; no code inspected/executed here.
    • how much was read: most of it read
    • record id: compositional-policy-learning-in-2023
  • Creusot higher-order iterators (2023)
    • title: Specifying and Verifying Higher-order Rust Iterators.
    • what: Defines a first-order framework for specifying Rust iterators, including nondeterministic, potentially infinite and effectful adapters. Iterators are described by a production relation over sequences; prophetic mutable-value semantics and closure contracts handle mutable borrows and Fn/FnMut callbacks. Creusot translates the contracts to Why3 verification conditions. Sections 3–6 define completed and production predicates, refinement of mutable references, closure pre/postconditions, and Map/MapExt adapters; MapExt carries ghost history for stateful effects. Range, IterMut, Skip, Take, Fuse, Map and MapExt plus clients (counter, decuple_range, hillel, knights_tour) are verified. The production relation intentionally permits underspecification such as hash-table order, requiring client properties to hold for all permitted sequences.
    • number: iterator proofs 0.40–1.06 s
    • number: Map and MapExt 7 manual steps each
    • number: client proofs 0.40–1.15 s
    • number: hillel 0.86 s; knights_tour 1.15 s
    • limits: The framework relies on safe Rust ownership/non-aliasing and first-order Why3 reasoning. Standard Map restricts closure preconditions to history-free ones; MapExt adds ghost state. Several proofs need manual quantifier instantiation or sequence lemmas. Filter, DoubleEndedIterator, ExactSizeIterator, lending iterators and automatic closure-contract inference are future work; this is not a distributed-protocol evaluation.
    • how much was read: most of it read
    • source
    • record id: creusot-higher-order-iterators-2023
  • Evangelou-Oost contextuality (2023)
    • title: Contextuality in distributed systems
    • what: Defines a lattice of distributed-program specifications as subpresheaves of relative execution traces paired with maximal covers of a finite topological variable space. The lattice order captures refinement and parallelism; associated information algebras define local and global consistency, with global consistency related to sequential consistency. The paper constructs relative traces from nondegenerate simplicial cells of products of variable prosets, proves the trace presheaf is flasque and a tuple system, and derives an ordered adjoint information algebra of relations. It characterizes local consistency by flasqueness and global consistency by an inference/join test. A dining-philosophers specification is locally consistent but globally inconsistent: three singleton traces induce a causal loop in chopstick acquisitions. Isabelle/HOL formalizes several constructions and proofs, while an explicit local-computation reformulation reduces join cost by projecting pairwise overlaps.
    • number: finite variable space
    • number: nine information-algebra axioms (I1–I9)
    • number: three-philosopher illustrative context
    • number: two consistency criteria: local and global
    • limits: The presentation assumes a finite variable set and nonempty per-variable prosets; finiteness simplifies the topology and lattice arguments. Relative traces preserve ordering but intentionally discard absolute timing, so the model does not represent synchronized clocks. Global-consistency computation is generally exponential in variables; the dining-philosophers demonstration omits detailed arithmetic of the final inconsistency. The work is mathematical and does not report measurements on deployed distributed systems.
    • how much was read: most of it read
    • record id: evangelou-oost-contextuality-2023
  • Lessons for Interactive Theorem Proving Researchers from a Survey of Coq Users (2023)
    • what: Analyzes the Coq Community Survey 2022, an online survey with 466 submitted responses, using descriptive comparisons and multiple-variable regressions. Regressions restrict to 390 recent users, then remove 18 without age, leaving 372 (367 for IDE satisfaction). It reports associations between experience, learner status, software-verification use, location and Coq tools, interfaces, satisfaction and requested improvements. Experience is associated with tool/library/CI/extraction use; software-verification respondents report more ecosystem-tool use and extraction. Results concern associations and a non-random respondent sample, not causal effects or all Coq users. Regressions first restrict to 390 respondents who used Coq in the last year, then exclude 18 without age, leaving 372 (367 for IDE satisfaction), Romano-Wolf adjusted p-values and a 0.1 threshold. Controls include age, gender, operating system, research area, employment and PhD. Robust examples include more than two years associated with CoqIDE use, North America with Emacs use, more than five years with lower favorite-IDE satisfaction and a larger excess of essential technical over community improvements, and software-verification use with new extraction-target requests. The paper explains why raw responses are withheld for privacy while code, generated plots and aggregated/open-text data are supplied. Figure 3 (p.12:13) ranks “Fixing bugs” and “Documentation” first by majority judgment: 62% of 299 answers and 56% of 342 answers, respectively, mark them “Essential”; question-specific denominators differ. These are respondents’ priorities, not measurements of improvement effectiveness.
    • number: {‘submitted_responses’: 466, ‘main_regression_n’: 372, ‘ide_satisfaction_n’: 367, ‘experience_over_2_years’: ‘64%’, ‘experience_over_5_years’: ‘40%’, ‘software_verification’: ‘67%’, ‘learners’: ‘17%’, ‘extraction_use’: ‘45%’, ‘ci_use’: ‘31%’}
    • limits: Survey recruitment targeted current or former Coq users through community forums and social networks; respondents self-selected and are not a random sample. Regression estimates cannot be interpreted causally; omitted correlated variables, question order, ambiguous questions and small subgroups threaten validity. Raw response data are not shared because of re-identification risk, so the supplied code cannot fully reproduce all analyses. Comparisons with Stack Overflow/Haskell surveys use different bin definitions and populations; Coq-to-ITP generalization is explicitly uncertain.
    • how much was read: most of it read
    • source
    • record id: lessons-for-interactive-theorem-2023
  • Lightning Network TLA+ (2023)
    • title: Towards a Formal Verification of the Lightning Network with TLA+
    • what: The paper splits the Lightning BOLT protocol into ten TLA+ specifications and nine refinement steps. The goal is to show that an adversary cannot steal an honest user’s funds. Two hard steps are model checked. The rest are done by hand.
    • number: ten specifications, nine proof steps
    • number: two steps checked: (IV)=>(V) and (IX)=>(X)
    • number: no state counts, runtimes, LOC or hours
    • number: No runtime or state-count table reported
    • limits: It is work in progress and not a complete theorem. It does not verify code. It has no full liveness proof.
    • how much was read: most of it read
    • source; notes: Towards a Formal Verification of the Lightning Network with TLA+
    • record id: lightning-network-tla-2023
  • Netrix guided consensus testing (2023)
    • title: A Domain Specific Language for Testing Consensus Implementations
    • what: Presents Netrix, a central networking server plus DSL for programmer-guided exploration of consensus implementations. Filters control message drops, delays, modifications and reordering; monitor state machines express safety/bounded-liveness assertions; residual nondeterminism is explored by PCTCP and tests are replayable. Formalizes protocol, monitor and product transition systems and proves monitor expressivity for complete runs. Instrumentation shims intercept RPC/message APIs; filters and key-value context encode semantic waypoints. Case studies cover Tendermint, Raft and BFTSmart across Go and Java, including regression tests and protocol-coverage measures. Filter-distance analysis predicts when PCTCP alone can find reorderings.
    • number: 34 unit tests total: 15 Tendermint, Raft tests, 8 BFTSmart (§5)
    • number: Instrumentation: 600 LOC added to 150k LOC Tendermint; 120/16k Raft; 150/16k BFTSmart
    • number: Tendermint found 4 new deviations; one liveness bug increased consensus time 30s→6min; fixes acknowledged
    • number: Raft tests found 4 documented bugs; PCTCP alone found none of new Tendermint or known Raft bugs
    • limits: Requires instrumenting communication APIs and serialization adapters; tests explore bounded executions (e.g., MaxEvents=1000, depth=10, 30s iterations), not exhaustive correctness. PCTCP cannot introduce Byzantine behavior and rapidly loses probability on deep reorderings. Findings are implementation-specific scenarios; passing tests do not prove safety or liveness. BFTSmart case found no bugs, possibly reflecting prior testing maturity.
    • how much was read: most of it read
    • source; notes: Netrix (2023)
    • record id: netrix-guided-consensus-testing-2023
  • Owl (2023)
    • title: Owl: Compositional Verification of Security Protocols via an Information-Flow Type System
    • what: A type system that tracks information flow. It automatically establishes computational secrecy and authenticity for a protocol written in the Owl language, and hands its refinement checks to Z3. It includes a Rust extractor that produces runnable prototypes.
    • number: Fig 13: Basic-Hash 46 Owl lines / 541 Rust / 0.71 s; Needham-Schroeder public 80 / 1019 / 7.74 s; Kerberos 270 / 3292 / 8.21 s
    • number: about 7,300 Haskell framework lines plus 580 shared Rust lines
    • limits: The proof for the core calculus is on paper. The extractor is not verified. Corruption is static. It has no injective correspondence (each run matches exactly one run on the other side) and no Kerberos freshness. It covers safety only.
    • how much was read: most of it read
    • source; notes: Related work absent from the first pass: Owl (2023)
    • record id: owl-2023
  • Strauss-Mitsch RSS verification (2023)
    • title: Slow Down, Move Over: A Case Study in Formal Verification, Refinement, and Testing of the Responsibility-Sensitive Safety Model for Self-Driving Cars
    • what: Formalizes longitudinal Responsibility-Sensitive Safety (RSS) as hybrid programs in differential dynamic logic, proves collision safety and minimal safe distances in KeYmaera X, proves deterministic controller refinement and verified compilation to Python, then uses formally derived ModelPlex monitors for testing and debugging. The model template makes acceleration, reaction-time, orientation, safe-distance and evolution-domain assumptions explicit. The same-direction proof uses an inductive stopping-distance invariant; opposite-direction safety uses a shared-responsibility invariant. Optimality is established constructively by choosing worst-case accelerations and showing any epsilon-smaller initial separation reaches collision. A deterministic det-HP controller is proved a refinement of the nondeterministic envelope, and structural induction proves Python compilation preserves reachable states. ModelPlex monitors connect runtime states to formal paths: faulty controllers trigger alarms, and collisions without alarms expose modeling flaws. Simulations explore reaction-time parameter effects after proof.
    • number: four RSS safety/optimality theorems
    • number: reaction-time examples rho=1 and rho=6
    • number: same-direction safe-distance invariant
    • number: det-HP to restricted Python compilation
    • limits: Safety is only for the longitudinal two-car kinematic model, with nonnegative directional velocities, bounded accelerations/decelerations, positive reaction time and initial safe separation; gear changes are assumed to occur only when stopped. The continuous dynamics use ideal kinematics and omit richer tire/friction physics. Python correctness theorem assumes Float=R (or interval arithmetic is needed), and compiled code inherits the restricted det-HP syntax. Testing samples scenarios and cannot replace proof; formal proof of the chosen model does not establish real-world fidelity.
    • how much was read: most of it read
    • record id: strauss-mitsch-rss-verification-2023
  • Tamarin to Gobra/VeriFast (2023)
    • title: Sound Verification of Security Protocols: From Design to Interoperable Implementations
    • what: Translates a Tamarin protocol model into separation-logic specs. Gobra (for Go) and VeriFast (for Java) check these against annotated code. This carries the secrecy and authentication already proved for the model over to the implementation. It was applied to an adapted WireGuard.
    • number: WireGuard: 608 Go lines, 3,936 spec/proof lines, 32% generated; about 250 Tamarin rule lines; checking 148/138 s
    • number: signed DH Go: 106 / 1,015 lines, 61% generated; Java: 113 / 1,022, 76%
    • number: model verification about 3 minutes
    • limits: Safety only, with no progress property. The adversary is Dolev-Yao (it controls the network). Network and crypto calls are trusted stubs. DDoS handling, metrics and load balancing were removed. Observational equivalence is future work.
    • how much was read: most of it read
    • source; notes: Related work absent from the first pass: Tamarin models to verified Go
    • record id: tamarin-to-gobra-verifast-2023
  • TLA+ ZooKeeper reliability (2023)
    • title: Leveraging TLA+ Specifications to Improve the Reliability of the ZooKeeper Coordination Service
    • what: Builds three linked TLA+ specifications for ZooKeeper/Zab: an abstract protocol specification, a detailed system specification serving as a super-document, and a test specification that drives explorative implementation testing. The protocol model captures Zab ordering and recovery; the system model refines implementation details and uses interaction-preserving abstraction to make TLC checking feasible; the test model and Met conformance framework generate traces for the Java implementation. The authors reproduce deep ZooKeeper bugs ZK-2845 and ZK-3911 involving accepted-log inconsistency or committed-log loss, and merged the specifications into Apache ZooKeeper.
    • number: protocol configurations reach tens of thousands of states in seconds
    • number: system configurations reach billions of states and some exceed 24 hours under stated limits
    • number: two deep bugs reproduced: ZK-2845 and ZK-3911
    • number: trace length limit 100 in simulation; model-checking time limit 24 hours and disk limit 100 GB
    • limits: The objective is usable specifications and automated testing rather than full verification. TLC explores bounded configurations, trace lengths and resource limits; the system-level state space can become intractable. Conformance depends on the abstraction and instrumentation mapping between model actions and implementation events, and does not prove all Java code behavior.
    • how much was read: most of it read
    • source; notes: ## ZooKeeper TLA+ specifications (2023)
    • record id: tla-zookeeper-reliability-2023
  • Verus OOPSLA 2023 (2023)
    • title: Verus: Verifying Rust Programs using Linear Ghost Types
    • what: It connects erased proof resources (ghost state, which exists only in the proof) to Rust ownership and imperative code.
    • number: 12 example programs in Table 1
    • number: XOR doubly-linked list: 385 total SLOC, 5.03 s
    • number: FIFO queue: 477 total SLOC, 4.58 s
    • number: Verus RwLock: 425 total SLOC, 4.44 s
    • limits: The formal result is for a small calculus. The termination claim covers specifications and proofs, not executable programs.
    • how much was read: most of it read
    • source; notes: S31
    • record id: verus-oopsla-2023-2023
  • VLSM Faulty Distributed Systems (2023)
    • title: Validating Labelled State Transition and Message Production Systems: A Theory for Modelling Faulty Distributed Systems
    • what: Introduces Validating Labeled State transition and Message production systems (VLSMs): labeled transition systems with validity predicates on transitions and recursively defined valid states/messages. Composition, validators, local/global equivocation evidence, fixed-set and weight-limited state/message-equivocation models, and Byzantine components are defined in one framework. The paper distinguishes constrained executions (arbitrary environment inputs) from valid executions (inputs producible by the VLSM), defines free/constrained composition and induced validators, and proves state/message equivocation trace correspondence under full-node assumptions. It models weight-limited equivocation by annotating states with observed equivocator sets, then defines Byzantine components that can emit authenticated messages arbitrarily. Theorems 7.1/7.2 reduce fixed or weight-bounded Byzantine behavior to equivocation as observed by validators; examples include multiplication VLSMs, UMO/MO/ELMO observers, and explicit counterexamples showing composition constraints can break equivalence.
    • number: All results and examples are formalized and checked in Coq
    • number: Theorem 6.1 gives two-way trace correspondence for fixed equivocators under full-node assumption
    • number: Theorem 7.1 equates non-Byzantine traces under fixed Byzantine and equivocation behavior
    • number: Theorem 7.2 gives the analogous weight-limited reduction
    • limits: Validity can be undecidable in general (Turing-machine example). Equivalence theorems require channel authentication, sent and full-node assumptions for components; arbitrary composition constraints can make state and message equivocation differ. Byzantine components are restricted from forging sender identities. The work is foundational and Coq-checked, not a performance benchmark or deployed protocol.
    • how much was read: most of it read
    • record id: vlsm-faulty-distributed-systems-2023
  • Agda abstract HotStuff/LibraBFT safety (2022)
    • title: Towards Formal Verification of HotStuff-based Byzantine Fault Tolerant Consensus in Agda: Extended Version
    • what: Defines an implementation-independent Agda model of HotStuff/LibraBFT for one epoch and machine-checks the core safety theorem (two committed blocks cannot conflict) plus CommitsDoNotConflictâ€Č, allowing non-participating clients to verify commits from partial record chains. Implementations instantiate EpochConfig and prove honest-peer assumptions once; liveness and cross-epoch reconfiguration remain outside the abstract proof. Abstracts Blocks, quorum certificates, RecordChains, CommitRule and implementation predicate InSys. The bft-assumption requires any two quorums to share an honest member; thmS5 proves committed blocks lie on one tree path modulo an explicit block-ID injectivity failure. The extended property uses RecordChainFrom and Complete ∈QC⇒AllSent to let clients validate only records needed for a commit. The paper refines non-injectivity to collisions among records actually in the system, linking abstract safety to cryptographic hash assumptions.
    • number: Single-epoch abstract model; no benchmark/runtime numbers reported
    • number: Common quorum instantiation: n>3f Byzantine bound and >2n/3 quorum (§3)
    • number: Agda 2.6-era open-source model/proofs; extended version adds proof details over NFM paper
    • limits: Proofs cover a single fixed epoch and 3-chain commit rule; 2-chain DiemBFT option and epoch changes are future work. Safety is conditional on quorum intersection, honest voting/record-membership assumptions and block-ID injectivity (or an explicit collision witness). Liveness is deliberately not meaningful for the abstract model; concrete implementations must prove handlers satisfy assumptions. No runtime performance evaluation is reported; contribution is machine-checked metatheory and open-source Agda code.
    • how much was read: most of it read
    • record id: agda-abstract-hotstuff-librabft-safety-2022
  • Cosmos DB TLA+ (2022)
    • title: Understanding Inconsistency in Azure Cosmos DB with TLA+
    • what: # Whole-paper read: Understanding Inconsistency in Azure Cosmos DB with TLA+ (authored by agents unless marked 🧑) A. Finn Hackett, Joshua Rowe and Markus Alexander Kuppe; arXiv2210.13661v1,24October2022,11pages. This is a client-facing behavioral model and industrial explanation case study. It reports390lines of core specification developed over2person-months,24non-type properties checked by bounded exploration/simulation, two documentation issues and an abstract explanation of an Azure outage. The service implementation is represented through expert feedback, without automated conformance checking. [Q0,Q1,Q11,Q19] ## Model and assumptions The four conceptual variables are an ordered write log, a universally replicated prefix readIndex, a durable majority-replicated prefix commitIndex, and a failover epoch. Their relationship is readIndex≀commitIndex≀Len(log). Replication nondeterministically increases either prefix; data loss truncates only the non-durable suffix and increases epoch. The log abstracts replica/region arrangements rather than enumerating them. The retrieved source additionally carries the configured write level as an unchanged state variable; the paper calls it a constant. [Q3,Q4,Q5,S1] One write consistency level is configured for a deployment; individual reads may select an allowed weaker level. The model concerns individual single-key operations. Transactions and optimistic concurrency are outside its scope. Bounded staleness models operation counts, omitting the wall-clock bound. VersionBound limits unreplicated entries for all write levels; StalenessBound separately limits non-durable entries when bounded-staleness writes are configured. These abstractions should not be mistaken for a proof covering arbitrary implementation arrangements merely because the model does not explicitly contain servers. [Q3,Q5,Q14] A write begins by appending its key/value and obtaining an epoch/checkpoint token. It can later succeed or fail. Failure need not delete the value: the request can have taken effect even if its response was lost. Weak reads can see the value while the write remains pending. Successful strong writes require durability. An epoch change invalidates all old session tokens in this model; authors acknowledge that real data loss need not invalidate every token. [Q6,Q7,Q9,Q18] GeneralRead(key,index,allowDirty) returns the latest mapping at or before index, or a not-found marker if absent. If dirty reads are allowed, it also permits later matching entries. Strong reads use commitIndex without dirty values; bounded-staleness reads use commitIndex with dirty values; session reads use max(token.checkpoint,readIndex) with dirty values and require a current-epoch or null token. The client updates its token with the maximum prior/read checkpoint. Prefix/eventual reads both use readIndex with dirty values. This last equivalence concerns single reads/writes, not transactions. [Q8,Q9,Q10,Q14] ## Validation and its limits Authors report10liveness and14safety properties across4distinct levels, excluding basic typing, using exhaustive logs up to length6 and depth-first random traces up to100steps. Examples include durable committed prefixes, read-your-writes, monotonic reads, staleness bounds, token lifetime and eventual write completion. The paper gives no complete per-property run logs, state counts, runtimes or mapping of every property to each exploration bound. These are bounded model checks and sampled traces, not a parameterized proof or implementation test. [Q11] The pinned artifact gives useful additional scope. MCCosmosDBProps uses two keys, three values, StalenessBound2,VersionBound3,Len(log)<3 and epoch<3. Its configuration labels several temporal checks “very very slow (1hr+)” and three “overloads TLC (out of memory), probably holds”. SimCosmosDBProps has a finite natural-number replacement0..100 and omits some costly properties. These comments are evidence about the retrieved snapshot, not proof that the paper’s historical runs failed; neither do they substantiate completion of every stated check. The history specification assumes weak fairness of the disjunction WriteSuccess√WriteFail; the simulation specification omits that fairness clause. Thus completion claims depend on the specification and bounds actually used. I did not establish an unbounded per-write progress theorem. [S2,S3,S4] CosmosDBLinearizability maps strong read results to an atomic dictionary view. A commitIndex jump can correspond to multiple dictionary writes in one abstract step. The saved configuration asks for DictSpec under epoch<3 and Len(log)<4. This supports the paper’s model-level refinement argument; I did not independently establish a full invocation/response-history linearizability theorem. The old-model refinement goes from the older model to this newer behavioral specification, so old behaviors are included in the new model. The claimed strictness additionally rests on the newer model admitting data loss and dirty reads omitted before. The retrieved mapping fixes two regions/two clients per region/one write region and constrains history length<5. I inspected the mapping, not its old-model dependency closure. [Q12,S5,S6] The read hierarchy is checked while holding write consistency fixed and considering all session-token choices. Comparing differently configured write levels does not give the same inclusion: strong writes can admit more pending non-durable values than bounded-staleness writes. The four retrieved adjacent read-refinement modules use fixed write configuration and small finite state constraints; no unbounded theorem proof is attached to their THEOREM declarations. [Q13,S7] ## Concrete cases and industrial results The first documentation issue is a claim that prefix reads cannot observe A,C or B,A,C after sequential writes A,B,C. A,C is possible simply by interleaving reads around writes. For B,A, use five replicas: A reaches1,2,3;B reaches1,4,5;one read hits5 and another2 before replication catches up. Each write reached a local majority, yet the client seesBthenA. These are allowed service behaviors, not newly demonstrated implementation failures. Authors report the documentation was rewritten. [Q14] The second issue concerns regional guarantees. Bounded-staleness operations in one region may appear strongly consistent until a region failover loses or exposes older data; they lack global durability. Authors report their argument was confirmed for individual operations, while regional documentation bullet points remained because transactions distinguish prefix and eventual behavior. The paper’s section title about regions must be read with that explicit restriction. [Q14] The outage affected thousands of subscriptions over28days and was noticed after26days. FrontDoor wrote task data, then asked Worker to read it. Session consistency was configured, but the processes used separate/unconfigured session tokens. Their cross-process interaction therefore had only eventual-read guarantees. A routing change exposed the existing semantic problem through latency. A PlusCal model reproduces a missing read before replication; forwarding FrontDoor’s token to Worker removes the modeled error according to the authors. The original postmortem author confirmed the explanation made sense. This is an abstract causal explanation and proposed/rechecked model fix, not evidence that the fix was deployed or that every production trace was matched. [Q15,Q16,Q17] Other cases show why the model has two-step writes: a weaker read can observe an incomplete strong write; a failed write can remain durable; and a bounded-staleness read under strong-write configuration lacks the separate bounded-staleness write throttle. Although the paper says strong consistency has no bound on in-progress requests, the model still has VersionBound on partially replicated entries; completed replication permits more pending requests. These are distinct quantities. Expert review caught an earlier incorrect atomic-write abstraction, which was rewritten and rechecked in2–3days. [Q18,Q19] ## Printed text versus pinned source The displayed WriteCanSucceed on paperp4 checks token validity and, for strong writes, token.epoch=epoch. It omits the checkpoint≀commitIndex condition that the immediately following prose says is required. The pinned CosmosDB.tla includes that durability conjunct. Thus the displayed formula and prose disagree; this does not establish that the checked source permits non-durable successful strong writes. [Q7,S1] The outage text’s expected formula is eventually workerValue=“workerValue”, but Listing1writes“taskValue“. The source’s temporal property uses eventually workerValue=“taskValue” and its terminal-state property checks the same literal. I treat the printed literal as a presentation mismatch and preserve the intended missing-task-value scenario rather than presenting the printed formula as a valid test of that scenario. [Q16,S8] These comparisons use a retrieved, pinned repository snapshot, not an asserted reconstruction of the exact2022experiment checkout. No author code or proof/checker was run. [S9] ## Contribution and reading scope For this database, the contribution is a reusable specification of a distributed dependency’s visible behavior and a concrete demonstration that model correctness also depends on choosing faithful abstractions. Its relevance to LLM-written specifications is my inference: evaluation should test behavior the model must permit as well as properties it must forbid, record expert corrections, and distinguish bounded self-consistency from service conformance. The paper has no Verus, Rust or LLM experiment. [Q19,Q20] Read all11pages,28reference entries, every displayed definition, Listing1,all4figures and TableI; inspected all11page renders across the preceding and current context. Read the complete core/property/read-wrapper/client/linearizability modules, both PlusCal outage modules, both model-check/simulation wrappers and configurations, four read-level refinement modules and their common-pattern constraints, the general-model mapping/configuration, and two repository READMEs.26static files acquired with hashes and Git blob identities. No old general-model dependency closure or broader implementation inspected. Official and inventory PDFs are byte-identical. No author execution/import, solver, compiler, checker or serialized scientific-results loading.
    • number: 2 person-month development
    • number: 10 liveness and 14 safety properties across 4 consistency levels
    • limits: single-keyindividualoperations;countnotwallclock;alltokensinvalidatedonepoch;boundedchecks;expertconformanceonly
    • how much was read: most of it read
    • source; notes: P24. Understanding Inconsistency in Azure Cosmos DB with TLA+
    • record id: cosmos-db-tla-2022
  • Event monads in Isabelle (2022)
    • title: Compositional Verification of Interacting Systems Using Event Monads
    • what: Defines event monads, event systems and Hoare rules in Isabelle/HOL, then composes independently verified handlers into correctness results for distributed summation, a German cache-coherence model and real-time partition scheduling. An event monad returns a set of value/state/output-trace triples and a failure flag, supporting nondeterminism, state updates, signal, bind and while loops. Preconditions and postconditions can depend on traces; an append-only trace frame rule preserves prior output, unlike simply treating traces as arbitrary state. Event systems map events to handlers; unhandled events become environment output, while emitted handled events execute recursively in sequence. Separate inductive reachability and guaranteed-termination predicates support partial/total Hoare rules. Pair and indexed-array lifting rules preserve untouched subsystem properties. The MapReduce model proves that alldone implies the accumulated sum is correct. Cache-coherence proves an invariant ensuring exclusive access for arbitrary N clients. The scheduler case proves watchdog representation refinement, scheduler refinement, their product composition and a final tick-level specification. Both no-switch and next-tick/next-window/next-frame switching cases reuse the watchdog proof.
    • number: 8948 total implementation/example lines
    • number: 1131 foundations; 726 MapReduce; 1261 cache coherence
    • number: 2572 watchdog lines reused by both scheduler versions
    • number: 723 no-switch scheduler; 2265 switching scheduler/system
    • limits: Interactions send events without waiting for immediate replies; all output events may be placed at function end. Handlers and the recursive event-dispatch semantics execute sequentially, so this is not a general concurrent interleaving or network-failure model. Unhandled events are delegated to the environment. Termination must be proved for recursive event chains and loops; MapReduce permits a server to skip progress forever and proves correctness conditional on alldone, not eventual completion. RTOS verification is at design level: parts resemble C, but AutoCorres C translation is not used; the concrete doubly-linked watchdog is abstracted to a list/array of relative deadlines. Case studies demonstrate functional correctness/refinement, not measured end-to-end implementation performance, schedulability for arbitrary workloads, or spatial separation of an entire OS.
    • how much was read: most of it read
    • record id: event-monads-in-isabelle-2022
  • Hemiola (2022)
    • title: Hemiola: A DSL and Verification Tools to Guide Design and Proof of Hierarchical Cache-Coherence Protocols.
    • what: A Coq-based language whose templates manage locking, so that invariant proofs consider one transaction at a time. It proves serializability and coherence of MSI/MESI cache models and compiles to Kami hardware.
    • number: over 10^9 memory requests per protocol in randomized FPGA tests
    • number: simulations of 500,000 cycles
    • limits: Verifying the compiler pipeline is future work. FPGA testing is not a general proof of liveness.
    • how much was read: most of it read
    • source; notes: Related work absent from the first pass: Hemiola
    • record id: hemiola-2022
  • Hoare calculus for reconfigurable distributed systems (2022)
    • title: Reasoning about Reconfigurations of Distributed Systems
    • what: Develops a Hoare-style calculus for programs that create/delete components and connectors while finite-state component behaviors continue. A separation-logic-inspired configuration logic uses inductive predicates for unbounded networks; havoc invariants capture interactions in unaffected parts, with an assume/rely-guarantee-style proof system. Defines primitive reconfiguration commands new/delete/connect/disconnect, local programs and frame rule, and havoc semantics allowing loose/tight interactions. Extended regular expressions describe interaction sequences; cyclic proofs establish havoc triples and soundness. Examples prove safety of self-adjustable tree architectures. Automation analysis shows configuration-logic entailment is 2EXP-complete under bounded-degree restrictions, while frame inference remains open.
    • number: No runtime benchmark; contribution is calculus and worked proofs
    • number: CL entailment is 2EXP-complete under stated restrictions (§7)
    • number: Havoc proof soundness established by Theorem 2 (§5.3)
    • limits: The main examples use finite-state event behaviors, ideal networks without packet loss or delays, and exogenous coordination; low-level mutex/CAS coordination is abstracted away. CL entailment is undecidable in general and 2EXP-complete only under syntactic and bounded-degree restrictions. Havoc proof rules require distinctive proof trees and cyclic-progress conditions. Frame inference and broadcast interactions are future work; timed/hybrid behaviors are not modeled.
    • how much was read: most of it read
    • record id: hoare-calculus-for-reconfigurable-distributed-systems-2022
  • On the Correctness of Speculative Consensus (2022)
    • what: # Whole-paper read: On the Correctness of Speculative Consensus (authored by agents unless marked 🧑) Jelle Hellings, Suyash Gupta, Sajjad Rahnama and Mohammad Sadoghi; arXiv2204.03552v1,7April2022,25pages. This is a detailed paper proof for Proof-of-Execution (PoE), a Byzantine state-machine replication protocol that speculatively executes before committing. Its main contribution is the connection between early client replies, preservation across view changes, eventual consensus and recovery of client results. The proof is mathematical prose and pseudocode, not a machine-checked development. [Q0–Q3,Q5–Q10] ## System and required conditions There are fixed replicas R, Byzantine replicas F, and clients C. The paper writes n=|R|,f=|F|,nf=n−f and assumes n>3f, authenticated communication and deterministic transaction execution. Byzantine replicas can coordinate and clients may all be malicious. Most exposition assumes publicly verifiable digital signatures; digest variants need cryptographic hash assumptions, and threshold variants need threshold signatures. This paper defines f from the fault set; it does not separately explain how deployments configure an upper bound used for quorum thresholds. [Q1,Q11–Q14] Weak consensus means decisions never conflict, while termination and forcing new decisions require periods of reliable communication with some unknown bounded delay. The advertised asynchronous recovery therefore does not give unconditional progress during arbitrary loss or delay. Assumption4.6 bounds proposal size and the number W of prepared but uncommitted rounds. This makes a single finite message-delay estimate applicable to protocol messages. Timeout estimates must eventually grow sufficiently large. The displayed backoff argument also requires a positive initial estimate; multiplying zero cannot make it positive. [Q1,Q6,Q8] ## Normal execution and recovery The primary in view v has id=v mod n. A signed client request is proposed in a round. Each honest replica prepares only one proposal for that round/view and broadcasts Prepare. A certificate collects nf matching preparations. Replicas execute speculatively after all preceding transactions have executed and send Inform to the client. The client needs nf identical, view-specific Inform replies as a proof of execution. The familiar f+1 reply threshold for committed execution is insufficient here because speculative executions can be rolled back. Theorem4.1 establishes same-view uniqueness and normal-case service with a good primary, reliable communication and identical execution history. [Q2,Q3] The printed Theorem4.1 contradiction proof defines T_i=S_i minus Byzantine replicas, but then treats S_i as if all its members were honest and as if those full sender sets were disjoint. Byzantine senders can vote for both proposals. The usual intersection argument applies to T_i, the honest subsets, instead. This is a notation defect in that displayed proof, not a demonstrated counterexample to same-view uniqueness. [Q3] The four-replica failure examples distinguish omission by a faulty primary, a false accusation by a faulty backup, and network loss. Other replicas can observe the same messages in all three cases. A malicious primary can leave some honest replicas without a proposal while the client still receives a proof of execution using Byzantine replies. Recovery therefore must preserve what a client could already have observed, rather than treating an isolated replica’s missing proposal as evidence that no execution occurred. [Q4] Check-commit is decentralized. An honest replica broadcasts its prepared certificate only after execution, while still in the view, and after all previous rounds have committed. Receiving a valid certificate lets a missing replica prepare and execute. A commit certificate collects nf CheckCommit messages. Theorem4.4 relates a client proof to eventual preparation at every honest replica, relates one honest commit to eventual commits/client proof given the shared prefix, and derives that a commit certificate entails nf−f honest executions plus commitments for earlier rounds. The first two statements assume reliable communication and all honest replicas in the view. Out-of-order proposals are supported; the proved base still commits in order. [Q5] View changes use three stages. A replica that detects failure rebroadcasts Failure. Receiving f+1 alerts induces an honest replica to join; nf alerts make it stop the old protocols and send ViewState to the next primary. State includes the latest commit certificate and every subsequently executed prepared certificate not rolled back. The next primary collects nf states and broadcasts NewView. Under reliable communication with delay ÎŽ, Lemma4.5 synchronizes entry into the proposal stage within2ÎŽ; Lemma4.7 delivers a good primary’s new-view proposal within4ÎŽ of the first such entry. [Q6] The new ledger retains the committed prefix through LC, then the latest-view prepared request in each round through LP. Missing committed history is queried; speculative requests outside the selected ledger are rolled back; the new primary must repropose selected uncommitted requests before new rounds. Theorem4.10 inducts over views to preserve any request executed by nf−f honest replicas, including every request with a possible client proof or commit certificate. Assumption4.8, uniqueness of the request named by commit certificates for a round, is a temporary proof hypothesis subsequently discharged by Corollary4.11. It is not an additional final assumption. [Q6,Q7] Lemma4.12 supplies QueryCC/RespondCC recovery of missing committed history. Lemma4.13 and Theorem4.15 use increasing timeout estimates and eventual good primaries to establish resumption once communication is reliable. The worked ÎŽ=30ms example starts estimates7,3,5,1ms; three doublings yield56,24,40,8ms, and the four replicas need3,4,3,5 doublings respectively. Remark4.17 suggests a practical cap such as10seconds, but the theorem’s unbounded-growth argument only carries to a cap when that cap exceeds actual reliable-network delay. [Q8] Theorem4.18 combines preservation, recovery and client-request forwarding to prove weak consensus. Honest clients repeatedly send an unanswered request to all replicas; replicas forward it or trigger view changes if it is not served. Suggested defenses against malicious clients include per-client forwarding limits and treating another request by the same client as evidence of a timely proposal. These are stated heuristics, not a quantified load-admission/fairness analysis. Recoverable non-Byzantine crashes require certificates in persistent storage; Remark4.19’s recovery claim depends on enough replicas recovering. [Q9] Consensus alone does not guarantee a client obtains nf identical replies from one view. Example4.20 partitions honest replicas into A,B,C of sizes f,f,1 and alternates unreachable groups across three views. The same request becomes decided, but view-specific replies and commit certificates remain split, so no ordinary proof of execution forms. The repair is InformCC: after an honest replica commits, it can send the view-independent round/result to a retrying client. Now f+1 matching InformCC replies suffice because at least one is honest and committed execution is preserved. Theorem4.21 proves service when communication is reliable. Client request order is not automatically enforced; waiting for the first result or validating per-client counters supplies an extra application policy. [Q10] ## Complexity, variants and evaluation Figure1 compares seven protocols/variants; Figure12 gives13 message/certificate rows and three size variants. These are analytical accounting, not measured experiments. Base PoE takes two replica communication rounds before execution and three through check-commit; Linear-PoE takes three and five. The table’s C parameter is request size, so expressions containing nC account for payload, not just the number of messages. Off-by-one terms are intentionally omitted in Figure1. Base prepared certificates have size O(nf+C); commit certificates O(nfÂČ+C), because different replicas may attach different prepared certificates. ViewState and NewView additionally depend on W. [Q1,Q11] Digests make most messages independent of request size but require explicit retrieval of missing request bodies and certificates. Replacing a certificate-carrying CheckCommit with a constant-size message requires f+1 matching senders before querying an honest holder. It does not eliminate the bounded-request-size assumption. Threshold signatures reduce certificates to constant size; by themselves they do not reduce all-to-all message counts. [Q12,Q13] Linear-PoE sends preparations through the primary. Its decentralized commit replacement rotates aggregator q=round mod n, commits a digest of the last n prepared certificates, and uses a separate n:(f+1) threshold scheme for recovery certificates before n:nf commit certificates. This prevents a fixed faulty aggregator from permanently hiding committed history. The pseudocode waits for commitments through round−n and covers the preceding n−1 rounds with the resulting certificate. Failure detection still broadcasts quadratically. The authors’ belief that such communication cannot be eliminated in their recovery setting is not an impossibility proof. The linear variant is explained by construction; it does not receive a separate full formal refinement proof here. [Q14] The MAC-only variant is a proposed redesign of the two new-view stages by analogy with PBFT; the paper does not print that redesign. Out-of-order processing means proposing future rounds within W while earlier decisions finish. It does not remove the sequential execution dependence or the proved base’s in-order commits. [Q15,Q16] The n=31,C=10KiB,M=256B bandwidth example reports322KiB for the base primary and315KiB with linear aggregation, approximately2percent savings. Direct substitution gives322.5KiB and315.7258KiB, about2.10percent. The primary still transmits the full proposal to every replica. The accompanying “roughly-1/3-th increase in latency” is inconsistent with the stated increase from two to three communication rounds: relative to two, that is50percent. This is a reader arithmetic observation, not an execution measurement. [Q14] Example5.6 assumes n=31,ÎŽ=15ms and1Gbit/s and prints22 sequential versus3028 out-of-order decisions/second. The22 figure follows1/(3ÎŽ)=22.22. The3028 figure is inconsistent with the printed bit/byte units: using10kB and256B gives about386.95 decisions/second; using10KiB gives378.51. The value3028.1 is obtained with10KiB if1Gbit/s is treated as10âčbytes/s. Either consistent byte interpretation still gives a bandwidth-only upper estimate, excluding computation and other bottlenecks. The paper’s two-orders-of-magnitude statement is therefore not supported by its stated inputs. [Q16] Section6 compares PBFT, Zyzzyva, SBFT, HotStuff and MinBFT using communication rounds and simplified costs. It qualifies Zyzzyva/SBFT fast paths, assumes PBFT-like checkpoint costs for SBFT, and identifies trusted hardware/reliable communication for MinBFT. The HotStuff discussion and33 decisions/second example are this paper’s account of a particular chained scheduling model, not an independently validated universal bound on HotStuff deployments. Its prediction that PoE outperforms PBFT “in all situations” exceeds what round counts alone establish: computation, rollback/recovery workload, implementations and resource bottlenecks are not measured here. [Q17–Q22] The introduction/conclusion claim an “analytical and experimental” evaluation. This saved25-page version contains analytical comparisons and hypothetical numeric examples, with no experimental setup, implementation measurements, repeated trials or measured plots. Its earlier EDBT2021 paper is reference18; results from that separate paper are not imported into this record. No proof assistant, model checker, Verus, verified Rust, TLA+ or LLM-agent experiment is reported. [Q0,Q17–Q24] ## Relevance and reading evidence For distributed verification, this contributes detailed proof obligations for speculative client observations, view-change preservation, the distinction between agreement and delivered service, and communication/recovery tradeoffs. My inference for proof-agent evaluation is to check eventual-reliability and bounded-window conditions, quorum intersections, temporary proof hypotheses, persistent crash state and units in analytical evaluation separately. A successful local proof script would not by itself establish any of those model-to-implementation connections. Read the complete25pages,40references,all15numbered figures including pseudocode and both tabular figures,all printed proofs/formulas/examples,and all25page renders. Official and inventory PDFs are byte-identical. No implementation or artifact source was linked as part of this paper’s proof/evaluation and none was inspected here. This record does not audit the related ResilientDB implementation or preceding EDBT paper. No author execution/import, compiler/checker/prover/solver run or serialized scientific-result loading.
    • limits: n>3f/authentication/deterministicexecution/boundedproposal_window/eventualreliablecommunication/positivegrowingtimeouts/persistentcertificates/paperproofnotmechanized/noempiricalmeasurements/printedunitdiscrepancies
    • how much was read: most of it read
    • source
    • record id: on-the-correctness-of-2022
  • SMR synchronizers and PBFT-light liveness (2022)
    • title: Liveness and Latency of Byzantine State-Machine Replication
    • what: Specifies an SMR synchronizer with application-controlled advance calls, supplies an O(n)-view-variable implementation tolerant of pre-GST message loss, and uses its interface to prove PBFT-light atomic-broadcast liveness and derive recovery/good-case latency bounds. The proceedings also describes extensions to periodic PBFT leader rotation and a HotStuff-like variant. Figure 1 separates Monotonicity, Validity, Bounded Entry, Startup and Progress. Figure 3 retains only each sender’s highest WISH and uses the (2f+1)st and (f+1)st order statistics plus periodic retransmission; it enters a view only when these agree. Bounded Entry holds eventually with d=2ÎŽ, provided no correct process requests a higher view during the entry interval. PBFT-light uses delivery and recovery timers, increasing both only on expiration. Lemma 6 shows that a correct process with recovery timeout >6ÎŽ and delivery timeout >4ÎŽ cannot initiate the first advance in a sufficiently late good view. Theorem 7 uses this to rule out executions where only a subset of correct processes increase timeouts indefinitely, then proves every valid broadcast by a correct process reaches all correct processes. Reliable DECISION retransmission also ensures dissemination of any already delivered value. Good-case delivery takes 4ÎŽ from a correct broadcaster, corresponding to 3ÎŽ from the leader. The analysis distinguishes unknown per-execution ÎŽ from a known conservative Δ used only for the latency bounds.
    • number: n=3f+1; quorums 2f+1; f+1 correct advance requests suffice for startup/progress
    • number: O(n) stored view variables; eventual entry skew d=2ÎŽ
    • number: good-view timer thresholds: dur_recovery>6ÎŽ; dur_delivery>4ÎŽ
    • number: Theorem 8 deadline: GST+ρ+max{ρ+ÎŽ,6Δ}+4Δ+max{ρ,ÎŽ}+7ÎŽ under its stated assumptions
    • limits: n=3f+1, at most f Byzantine processes, authenticated point-to-point communication, signatures and collision-resistant hashing. Partial synchrony: unknown GST and ÎŽ; before GST messages may be lost/delayed and clocks drift unboundedly; after GST correct-process delays are ≀Ύ and clocks track real time. Correct clients invoke advance at most once between new_view notifications. Correct broadcasts are valid and unique. PBFT-light uses signatures and omits checkpoints/watermarks; reliable DECISION broadcast requires retransmission omitted from pseudocode. Latency results additionally assume known Δ>ÎŽ, timeout caps 6Δ/4Δ, retransmission period ρ and reliable-broadcast latency ≀Ύ+ρ. Theorem 8 assumes sufficiently large timeouts already at GST and a correct leader(V); Theorem 9 assumes synchronous startup, correct leader(1), timeout bounds and the view-1 optimization. Full synchronizer proof, PBFT safety proof, portions of timer proof, latency proofs, periodic-leader and HotStuff protocol details, and textbook-bug details are explicitly deferred to arXiv:2202.06679, which was not read in this batch. Theoretical proof, not a machine-checked artifact or implementation performance experiment.
    • how much was read: most of it read
    • source
    • record id: smr-synchronizers-and-pbft-light-liveness-2022
  • TLA+ verification trifecta (2022)
    • title: Specification and Verification With the TLA+ Trifecta: TLC, Apalache, and TLAPS
    • what: Uses a TLA+ specification of asynchronous termination detection and Safra’s ring algorithm to demonstrate complementary verification with TLC explicit-state checking, Apalache bounded/SMT and inductive-invariant checking, and TLAPS theorem proving, including refinement from the algorithm to a high-level state machine. The high-level module specifies active nodes, pending messages, termination detection, safety, liveness under weak fairness, and quiescence. Safra’s algorithm adds white/black colors, message counters and a circulating token; termination requires an inactive node 0, no pending messages, white token/node, and zero accumulated counter. TLC finds 4,097 states for N=4,K=3 in the abstract model and 1.3 million (N=3,K=C=3,Q=9) or 219 million (N=4 with same bounds) in the algorithm model, exposing state explosion and a token-color bug. Apalache checks bounded prefixes, proves an inductive invariant for N=100 in 20 seconds, and checks quiescence for N=100 in 11 seconds. Refinement is checked for small N; TLAPS proves type, safety, liveness, and refinement for arbitrary instances, with an invariant proof taking about 230 lines and liveness/refinement about 245 lines. The conclusion recommends TLC first, Apalache for inductive invariants, TLC/random exploration for liveness, then TLAPS for higher confidence.
    • number: 4097 states for high-level TLC N=4,K=3
    • number: 262145 states for high-level N=6,K=3
    • number: 1.3 million states for Safra N=3,K=C=3,Q=9
    • number: 219 million states and about 50 min for Safra N=4
    • limits: The abstract model assumes a nonzero finite N, natural pending-message counters, asynchronous actions and weak fairness only for DetectTermination; stronger fairness is optional but unnecessary for the stated liveness. TLC requires finite bounds on pending messages/counters for exhaustive checking, so finite checks cannot establish arbitrary executions. Apalache handles bounded prefixes and inductive invariants but needs type annotations and human-discovered invariants; it cannot directly handle the fairness temporal property. TLAPS proof effort is manual and backend-dependent. The Safra case is a ring algorithm and does not evaluate throughput, deployment behavior, or other distributed topologies.
    • how much was read: most of it read
    • record id: tla-verification-trifecta-2022
  • AWS S3 automated reasoning blog (2021)
    • title: How automated reasoning helps Amazon S3 innovate at scale
    • what: AWS describes S3 automated reasoning: mathematically specified properties, lightweight model checking and property-based testing for ShardStore Rust, with validation on every deployment and failure scenarios including device and Availability Zone failures.
    • number: S3 is described as over 300 microservices; blog says traditional proof can require up to 10x more effort
    • limits: Industry account; claims are not independently audited here and the model abstracts implementation details.
    • how much was read: most of it read
    • source
    • record id: aws-s3-automated-reasoning-blog-2021
  • Dijkstra Monads Forever: Termination-Sensitive Specifications for Interaction Trees (2021)
  • DSS (2021)
    • title: Detectable Sequential Specifications for Recoverable Shared Objects
    • what: Defines detectability by transforming an ordinary sequential object specification into a detectable sequential specification (DSS). Per-process abstract state remembers a prepared operation and its response. prep-op announces the operation, exec-op performs it, and resolve reports whether it took effect and its response; ordinary operations remain available without detection. Section 2 gives the state transformation and four operation axioms. prep-op and resolve are total and idempotent, while exec-op requires the matching prepared operation with no recorded response. An auxiliary parity bit can distinguish repeated identical operations. DSS is combined with a separate concurrency correctness condition and leaves nesting recovery to the application. Section 3 derives a queue from the Michael–Scott/durable queue: tagged per-thread pointers record operation preparation and completion, CAS and helping maintain the linked list, and Appendix A supplies a centralized recovery scan. A variation replaces centralized recovery with individual recovery. Theorem 1 states lock-freedom and strict linearizability, but the article omits the analysis and detailed model. Section 4 measures failure-free queue throughput on real Optane memory.
    • number: up to 20 threads on 20 cores
    • number: 30-second runs, ten runs per point, standard deviation <2% of mean
    • number: non-detectable DSS nearly 3× detectable DSS throughput at low parallelism
    • number: MS up to 1.5× non-detectable DSS at two threads
    • limits: A recovering process must retain its identifier across crashes to query its previous operation; this conflicts with the fresh-identifier model underlying durable linearizability. DSS specifies sequential behavior and requires a separate concurrent correctness condition. The queue uses asynchronous shared memory, persistent memory, volatile caches, explicit flushes and system-wide crashes. Correct nesting is an application responsibility. The correctness theorem is stated rather than proved in this article. Experiments cover failure-free runs, use debug compilation at O0 and sequentially consistent atomics, and do not measure crash recovery latency. The log queue comparator is the authors’ implementation and could be optimized further.
    • how much was read: most of it read
    • source
    • record id: dss-2021
  • Metastable failures (2021)
    • title: Metastable failures in distributed systems
    • what: Names a failure pattern in which a trigger (for example a short network outage) pushes a system into a bad state that a feedback loop (for example client retries) keeps going after the trigger is gone. Gives four production examples and a vocabulary: stable, vulnerable, metastable, trigger, sustaining effect, hidden capacity.
    • number: Retry example: 280 queries per second (QPS) plus a 10 s outage leads to 560 QPS of retries; recovery needs load under 150 QPS or retries under 20 QPS
    • number: Look-aside cache example: advertised capacity 3,000 QPS, hidden capacity 300 QPS; losing a 90% hit-rate cache gives 10x query amplification
    • number: Link imbalance example went unexplained for more than two years; fix was a single line in the connection-pool policy
    • number: A geo-distributed system with added retries and failover had worst-case work amplification over 100x
    • limits: A vision paper from operating experience: no formal definition of the property, no tool, no measured evaluation; the authors list how to find unknown metastable failures as open.
    • how much was read: most of it read
    • source; notes: ## Metastable failures (2021)
    • record id: metastable-failures-2021
  • MongoRaftReconfig TLA+ verification (2021)
    • title: Formal Verification of a Distributed Dynamic Reconfiguration Protocol
    • what: Machine-checks a TLA+ inductive invariant and TLAPS safety proofs for MongoRaftReconfig, proving LeaderCompleteness and StateMachineSafety for MongoDB Raft-based dynamic reconfiguration. Presents 359-line protocol spec, 140-line 20-conjunct invariant, decomposition into 160 proof goals, detailed TLAPS proof example, TLC-assisted invariant discovery, proof statistics and limitations.
    • number: 3189 lines TLA+ total
    • number: 359 lines protocol specification
    • number: 140 lines invariant
    • number: 20 invariant conjuncts
    • limits: Specification deliberately abstracts lower-level implementation details; finite TLC invariant search is probabilistic and not itself a proof. Safety only; liveness left future work. TLAPS backend solver can fail without distinguishing false from hard obligations; no verified runnable implementation. Full TLA+ and proof code supplied as supplementary material.
    • how much was read: most of it read
    • source
    • record id: mongoraftreconfig-tla-verification-2021
  • Specifying Message Formats with Contiguity Types (2021)
    • what: Introduces contiguity types, a formal-language layer for self-describing binary messages with records, arrays and guarded alternatives. Defines semantics over byte strings and a matcher computing field slices. Proves termination, substitution reconstruction and soundness in HOL4; completeness is not proved. Extends the matcher and proofs with empty languages and tagged lists. Applies filters/parsers to OpenUxAS LMCP messages. The formalism treats a base contiguity type as a set of strings of fixed width rather than a set of program values. Array lengths and alternatives can read earlier message fields through L-values; partial expression evaluation yields an empty language. The matcher returns an assignment from L-values to byte slices, enabling filters and test generation. Recursive list encodings handle finite nested structures but recursive first-order terms require mutual recursive constructions. The UxAS application adds semantic assertions for GPS ranges, bounded optional arrays and enumerations; filters and parsers were instantiated and tested with the UxAS simulator. The HOL4 model is supplied as supplementary material. Assertions should precede arrays so limits are checked before allocation. First-order terms with nested recursive term lists are a challenge needing more elaborate mutual recursion, rather than an already verified general construction.
    • number: {‘application’: ‘LMCP messages in OpenUxAS; payload and key-value arrays bounded at 8 and 32 in shown example’}
    • limits: Messages are contiguous byte arrays/strings; interpretation functions map leaf byte strings to numbers/booleans. Expression evaluation can fail when a referenced L-value is absent; the presentation omits error-handling details but HOL4 formalization models option failure. Current matcher is interpreted and copies or indexes slices; compilation to CakeML and a correctness proof are future work. Application testing reports successful simulator tests, but no size, speed or fault-detection measurements are given. Matcher soundness and reconstruction are proved; completeness has not been tackled. Tagged-list extension verified, generalized nested-recursive term handling needs further work.
    • how much was read: most of it read
    • source
    • record id: specifying-message-formats-with-2021
  • Verifiable Aircraft Engine Methodology (2021)
    • title: A Methodology for Developing a Verifiable Aircraft Engine Controller from Formal Requirements
    • what: Presents a three-phase, requirements-driven methodology for developing and verifying an aircraft engine controller: elicit and formalize requirements in FRET, verify through FRET-supported Simulink/Kind2 and FRET-guided formal models, then assemble a traceable verification report. The paper details the fretish intermediate language, FRET-generated LTL and CoCoSpec contracts, the parallel Phase 2A/2B toolchains, and feedback loops that revise requirements when verification exposes errors. The industrial use case translates 14 natural-language requirements and uses 20 supplied test cases to add detail; the authors explain how combining independent designs can expose inconsistencies.
    • number: 14 aircraft-engine requirements translated into fretish
    • number: 20 supplied test cases informed requirement elaboration
    • number: two parallel verification streams (FRET-supported and FRET-guided)
    • limits: The methodology is demonstrated on one industrial aircraft-engine-controller use case and remains ongoing work rather than a completed large-scale evaluation. Phase 2A checks are limited to properties expressible in fretish and Simulink/Kind2 tooling can lack scalability for complex requirements; Phase 2B model construction and translations may be manual. Requirement and design updates still require human work.
    • how much was read: most of it read
    • record id: verifiable-aircraft-engine-methodology-2021
  • What’s Live (2021)
    • title: What’s Live? Understanding Distributed Consensus
    • what: Extracts published liveness statements for consensus algorithms and formalizes them in TLA+. It compares what each one assumes and guarantees: 3 link assumptions, 7 server assumptions and 6 progress assertions. It also runs finite TLC experiments.
    • number: of 31 algorithms in Table 1, only 18 (58%) mention liveness and 11 (35%) give a liveness proof
    • number: TLC on up to 4 proposers and 4 acceptors in a few hours
    • number: 31 algorithms/variants are catalogued; 18 state liveness assertions, and only 11/31 (35%) provide some liveness proof.
    • number: TLA+ TLC illustrations cover up to 4 proposers and 4 acceptors for single-value Paxos; multi-value/larger cases become too expensive.
    • limits: It is an analytical comparison plus finite TLC runs, not new verified code. Appendix A uses a tick bound. Hours and lines of code are not stated.
    • how much was read: most of it read
    • source; notes: What’s Live? Understanding Distributed Consensus
    • record id: what-s-live-2021
  • Aneris (2020)
    • title: Aneris: A Mechanised Logic for Modular Reasoning about Distributed Systems
    • what: Aneris is a Coq-mechanized higher-order distributed concurrent separation logic for modular specification, partial correctness and refinement; the repository contains examples and case studies.
    • number: load balancer impl/spec/proof 18/78/95 lines
    • number: two-phase commit: 18 and 11 impl lines, 181 joint spec lines, 265 and 280 proof lines
    • number: replicated logging plus commit: 1,272 lines
    • limits: README-level account; publications linked from the README are separate sources.
    • how much was read: most of it read
    • source; notes: papers
    • record id: aneris-2020
  • Aragog (2020)
    • title: Aragog: Scalable Runtime Verification of Shardable Networked Systems
    • what: Operators write patterns of bad event sequences. Aragog compiles them into state machines and checks them against live or recorded event streams from networked systems. It splits the work by grouping keys.
    • number: 8 NAT policies at 5-14 spec lines, 3 firewall policies at 4-6 lines
    • number: four bugs in the NAT gateway, confirmed by operators
    • number: over 500,000 events/s for one policy, over 30,000 for eight
    • number: firewall violation detected in about 70 ms median
    • limits: Aragog has no correctness proof. It needs accurate event ordering and synchronized clocks. Sampling can miss flows. Operators write the specs.
    • how much was read: most of it read
    • source; notes: Aragog: Scalable Runtime Verification of Shardable Networked Systems; notes: Aragog: Scalable Runtime Verification of Shardable Networked Systems
    • record id: aragog-2020
  • Automated Verification of Customizable Middlebox Properties with Gravel (2020)
    • what: Gravel checks high-level trace properties of Click middleboxes in two stages: symbolic graph execution over Python element specifications, then LLVM symbolic execution/refinement of each C++ element against its specification. Run-to-completion handlers, restricted pointer analyses, loop unrolling, SMT models of Vector/HashSet/HashMap and concrete immutable classifier rules make most studied elements encodable. Developers still supply the high-level properties, intermediate element models and induction obligations. Records exact empirical screen/failure classes, graph-versus-element obligations, bounded graph/unrolling failures, SMT model/trust/init limits, explicit liveness/induction formulas, all13propertyscopes and full appendix examples/discrepancies, complete LOC/time/bug/performance cells and workload/selection limitations.
    • limits: §§2,3.1: Study is run-to-completion Click elements/configurations in official repository, not arbitrary concurrent network software. Element private state/event handler semantics and fixed directed topology underlie composition. Packet/time events modeled as state transitions; no shared-memory concurrent handler/interleaving proof or distributed consensus/failure model is presented. §2/Table1: Percentages measure ability to symbolically encode examined code after techniques/modifications, not verified high-level properties for226elements/37configurations. Baseline uses conservative no-pointer/no-loop criteria; later supports immutable unaliased singleton/array pointers, staticbounds, byte-valued uninterpretedfunctions and boundedunrolling. Error at limit is failed verification, not bounded-prefix success. §§2.3,4.2/AppendixA: Vector/HashSet/HashMap implementations replaced by SMT interface models. Paper supplies encodings rather than refinement proof of those underlying library implementations; their faithfulness/implementation correctness is an additional assumption despite terse §4.3TCBlist. Arbitrary recursive/custom datastructures unsupported. Generic payloadloops/AES andsymbolicstate-dependentloops remain obstacles. §2.3: Classifier rules are instantiated from concrete Click configuration; verifier checks transitiontableimmutable and symbolicallyprocesses packets with those fixedrules. This is configuration-specific verification, not a theorem for arbitrary ruleconfigurations or mutablepolicyupdates. §§3–4: High-level spec and element-level specs required. Element models are checked against LLVM so not simply trusted, but abstract operations/runtime and packet/state representation relation remain trusted. Compilation frontend/LLVM/back-end toolchain and Python/Z3/Clickruntime are inexplicitTCB. No verifiedNIC/OS/DPDK/hardwarestack. §4 Theorems1–2 are checker obligations: graphcomposition meets suppliedhighlevelproperty; each concretepossibletransition has counterparts in elementmodel. Paper describes symbolicchecks, not mechanized metatheory proving wholeverifier sound. Counterexamples dependonfaithfulmodels;specificationadequacy remainshumanobligation. §§3.3,4.1: Property1 calledliveness is immediateTCP-input→nonnull-outputcondition on terminatinghandler. It is not fair-scheduler/eventualdelivery/failure-recoveryliveness. Unboundedtrace persistence instead uses explicitbaseandpacket/timepreservation obligations; no bound on numberofevents if inductionvalid. Graphcycles allowed but maximumtraversal capmustsuffice (ToyLB6); hittingcap rejects. §5.3/Table3: Initialization assumedcorrect; malformedconfigurationcrash excludedfromguarantee. Paper does not prove construction/boot/configuration parser correctness. Bitvectorpacket/time/countersemantics and any time-wrap/monotonicity/precondition adequacy mustmatchspec; no general real-time guarantee beyondwrittenformulas. §5.1: MazuNATRFC5382properties omitICMPbecauseunsupported. Showingselectedmapping/filtering/hairpinning/memorization/payloadproperties is not fullRFCcompliance. Roundrobin andMaglevLB are bothdiscussed;fiveTable2applicationrows not anenumerationofeverypossibleLBvariant. §5.3: OriginalMazuNATendpoint-independence mismatch found/fixed is actualverificationfinding. Table3is manualassessmentofexistingbugreports/CVE-relatedsearch,not replayedinjectedbugsuite. Authorsscreen30recentbugs,exclude20 (10unsupportedfeatures,3docs,5CLI,2performance),thenclassify7/10preventable. Cannotgeneralize7/10toallbugs orclaim30experimentallycaught. §5.4/Table4: FiveconcurrentTCPflows/iperfthroughput,NPtcp200byteRTT,twohosts40Gbps,not saturatedsmallpacketMpps/adversarialstatechurn/largeflowcountbenchmark. ±values areprintedwithoutdefinedsamplecount/statistictype here. NATmeanRTT14.43→15.14us (~4.9%increase),soauthornegligibleoverheadclaimdoesnotmeanalllatenciesidentical. Replacingpriorityqueuewithlinearscanmayhaveunmeasuredscalingcost. §1/Table2: Introapplicationsequence assigns1151LOC/70highlevelLOCtoloadbalancer and1447/68tofirewall;Table2labels1151/70asFirewalland1447/68asLoadBalancer. SavedTable2labels asprimarystructureddata andnotedsourcediscrepancy. §3.4,p.229/AppendixA,p.236: Prose/filterexample saysremoveallmatchingpredicateentries, butAppendixAprintsnewcontain(k)=p(k,fvalue), withneitheroldcontainconjunctionnorpredicatenegation. mapformulaalso passesfvalueratherthanexplicitfvalue(k). Sourceequationsretainedasdiscrepancy; noimplementedunsoundnessallegationwithoutartifactcheck. §§3.2–3.3/AppendixB: ToyLBproseusuallyrewritesdestination,butProperty1callsencapsulated andappendixnewflowusesinner_ipwhileknownflowusesip4. MainpropertycodeprovesnonnullTCPoutput,notexactencapsulation. AppendixCmemorizationusesc/steer_towithdefinitionnotincluded andbasecreatesp1unused;printedexamplesalonearenotverifiedartifactreproduction. §6: Specificationsstillrequirehumaninduction/designdespiteautomatedsolverchecks. NoVerus/verifiedRust,TLA+,LLM-agentorwhole-networkroutingloopresult;non-Click/XDPextensionisproposedpossibilitynotimplementedmeasurement.
    • how much was read: most of it read
    • source
    • record id: automated-verification-of-customizable-2020
  • Config2Spec: Mining Network Specifications from Network Configurations (2020)
    • what: Config2Spec mines every policy in a chosen finite policy language that holds for all link-failure environments allowed by a model. It intersects policies inferred from sampled forwarding states with a candidate set, then uses grouped symbolic control-plane queries to verify remaining policies or produce counterexamples. Two runtime predictors choose between sampling and verification; policy-aware sampling, topology cuts and prefix grouping reduce work. A handwritten argument establishes exactness and termination conditional on exact terminating component tools and correct environment enumeration. Evaluation measures runtime, query reduction and specification size. Records the candidate/specification/verified invariant, universal failure semantics and finite policy-language boundary, complete predictor equations/initialization/smoothing, randomized unseen-environment requirement, dominator/shortest-path inference, SMT query polarity, fixed-link topology reduction, full algorithm/correctness argument, qualified forced-down environment-count concern, all table cells, parser/model edits to Internet2, and numeric discrepancies in summary claims.
    • limits: §§1/2: The mined specification describes behavior already enforced by the configuration, including mistakes or unintended restrictions. It does not discover operator intent or certify that existing behavior is desirable. An independent intended policy remains necessary to identify bugs; mined policies can support regression checking or refactoring only within the chosen semantics and failure scope. §2: Policy language includes reachability(r,p), isolation(r,p), waypoint(r,w,p), loadbalancing(r,p) on at least two paths. All policies means all instantiations of these supported templates, not arbitrary temporal/security/performance specifications. No convergence, transient update, quantitative bandwidth, timing or distributed liveness property is mined. §2: Failure model partitions links into forced-up, forced-down, symbolic; k bounds total down links including forced-down ones. Each concrete environment fixes all links and must satisfy that partition and count. Policy holds only if true in every admissible environment. Need consistent inputs k≄|Ldown|; empty-environment/vacuity handling not developed. Link-failure scope does not imply arbitrary router/software/Byzantine failures. §§3.2/Appendix A: Maintain verified⊆true specification⊆cands. Exact data-plane inference on a genuine admissible sample removes only false universal policies; sound complete control-plane query adds true policies or removes those violated by witness. Equality yields exact result; exhausting all genuine environments permits verified=cands. Proof assumes both tools model same configuration/policy semantics and their own results are correct. Appendix A: Termination relies on finite policy/environment spaces, PickCE always returning a previously unseen admissible environment, and every nonempty verifier query either proving policies or returning a real witness violating at least one. All component calls must terminate. No handling of solver unknown, timeout, parser errors or conflicting tool models is included in this theorem. Random sampling alone does not prove finite bounded runtime. Appendix A Algorithm1 line5 candidate listing error: totalEnvs=ÎŁj=0..k binom(|Lsymbolic|,j), but §2 defines k as total failures including forced-down links. Correct admissible count uses k−|Ldown|. Example one forced-down link, one symbolic link, k1: one admissible environment, listing counts2; exhaustion branch may never trigger and PickCE can be asked for nonexistent unseen environment. Source §7 correctly subtracts forced-down count for topology trimming. This is a printed algorithm concern, not an executed artifact failure; experiments use empty forced sets. Appendix A Algorithm1: No explicit TopoTrim call or moving-average history appears despite §§3/4 implementation description; line25 divides by a set rather than its cardinality in print. Initialization calls verifier ten times and can classify policies before first data-plane sample, even though performance discussion says k1 only DPA. Read listing as schematic; exact code correspondence not proved. §4: Time-per-policy estimator=last runtime/newly classified policies, with infinity on zero DPA progress; remaining-time estimator=per-call time×unseen environments or unclassified policies. DPA selected when either estimator prefers it. Initial DPA times0, ten verifier policy sets initialize verifier averages, last ten calls smooth times. Heuristic choice affects cost, not exactness if underlying invariants/progress hold; no optimal scheduling bound. §5.1: Policy graph edge weight counts unclassified policies using a previous forwarding graph. Weighted random failed-link choice prioritizes many dependencies but rerouting can preserve them. Deterministic heaviest-link selection observed to oscillate; random fallback returns an unseen environment. Need legal fixed-link/count enforcement and finite unseen selection; no guarantee weighted sampler always needs fewer samples. §5.2: Batfish computes forwarding states, one graph per equivalence class of destination prefixes sharing forwarding. Dominator tree includes routers with at least one destination path, yields reachability and mandatory waypoint policies; isolation is inferred when reachability absent. Precise path quantification and treatment of ECMP branches/loops/drops must match verifier. Paper does not prove Batfish/Minesweeper correspondence for all supported policies. §5.2: Load balancing inferred from multiple equal-cost shortest paths. This is path multiplicity, not balanced byte counts, per-flow hashing fairness, disjoint paths or guaranteed throughput. Text says shortest paths in the network after describing forwarding graphs; ACL/route-policy-aware interpretation must be supplied by implementation, not assumed from raw physical connectivity alone. §6: Query formula φnet∧φfailure∧(∧policypredicates). UNSAT certifies whole group; SAT witnesses at least one failed policy, not all. Remove only actually violated policies; remaining ones unclassified. Group maximal same-prefix policies, arbitrary prefix choice. Claimed always at least as good follows query-count classification argument, not a wall-clock guarantee because larger conjunction can cost more or time out. §7: TopoTrim removes forced-down links, reduces residual budget k, replaces each forced-up edge with k extra parallel copies, then computes(k+1)-edge-connected components. Lack of required reachability/connectivity prunes reachability/load balancing and waypoint endpoints. This is necessary topology feasibility, not sufficient routing correctness. Requires compatible undirected link-failure model, prefix attachment and nonvacuous waypoint semantics; isolation is not trimmed. §8: Implementation5KPython/Java uses Batfish and Minesweeper extended with waypoint/load-balancing. Feature limits/parser bugs/SMT encoding become trusted boundaries. No mechanically checked framework proof, verified parser or proof of executable implementation. Tool-specific precision is assumed by mathematical argument rather than independently established through differential correctness evaluation. §8: Evaluated NetComplete-synthesized OSPF/BGP configs on three topologies and2/4/8/16prefix path-ordering specs, five config sets/type/topology. Large-network waypoints supplied by operator, simulated with random20%routers. Output completeness therefore relative to selected waypoint domain, not all possible waypoint devices. Not a benchmark of recovering independently authored human requirements. §8/Table2/3: Reported values are averages across generated configurations; fractional policies are averaged counts, not actual fractional policies. Candidates count after first all-symbolic-up sample, not entire template space. Increasing k shrinks true-policy set for same config; the paper does not explain why first-sample candidate averages differ across k. §8.1/Table2 discrepancy: source repeatedly claims OSPF completion within2.7hours, but USCarrier k2 OSPF cell10528.4s≈2.925h. BGP49151s≈13.653h agrees13.7. Source trend k1→2→3 describes averaged rows; time can decrease at more permissive failure bound because trimming eliminates nearly all policies. No monotone-runtime guarantee. §8.2: Baseline comparison only OSPF grids20/25/30routers because baselines do not scale to large topologies; five config sets, k1–3. At k2/3 DPA speedup mean10.2/max41, CPV mean3.8/max8.3. At k1 plain DPA wins by mean24/max37seconds due verifier initialization. Large-topology runtime is not direct large-topology measured baseline speedup. §8.3/Table4: Sampler comparison ten OSPF/BGP config runs per topology,k3; weighted policy-aware generally prunes more, but random transitions earlier in6/30runs due stalled pruning, not necessarily better results. More expensive sampling22.1–358.2ms versus random.5–1.4ms; overall DPA1.4–57.8s. AddedSamples>500 is censored, not precise mean. Candidate percentages use first sample as denominator. §8.3: Query reductions measured against one-query-per-policy baseline at first transition, not runtime speedups. BICS k2 text51.1%trim/41.5%group yields7.4%remaining arithmetically, whereas text/plot give9.6%; 90.3%overall reduction versus9.6%remaining differs rounding/definitions. USCarrier text1.15%trimremaining differs from the plotted trimming result; the text and plot relationship is unexplained. The final0.04%groupremaining is retained as a source claim. §8.4: Internet2 real May2015 configs modified before analysis: remove parsing/logging/anonymization/BFD lines and unsupported community/empty-prefix-list route-map matches. Authors say internal-prefix-only/noexternalpeers makes latter irrelevant, but no independent semantic equivalence proof. >90Klines,10routers/18links is small topology with large config text, not158routerproductiondeployment. §8: VMs32GBRAM/12vcores@2.3GHz. No exact CPUmodel, sourceversions/commits, solverlimit/unknownpolicy, seeds, standarderrors/confidenceintervals or per-run maxruntime provided. Timings and simulation/SMT outcomes measure performance under component assumptions, not tool code correctness. §§1/9: Operator anecdotes motivate need but no controlled user study of usability/specification review, bug detection accuracy or deployment benefit. CEGIS analogy concerns enumerating all valid finite policies with examples/oracles, not a learned or LLM-generated intent specification. No Verus/Rust/TLA+ or LLM agent result.
    • how much was read: most of it read
    • source
    • record id: config2spec-mining-network-specifications-2020
  • FRET (2020)
    • title: Formal Requirements Elicitation with FRET
    • what: FRET lets users write requirements in a restricted English called FRETish. Each requirement has scope, condition, component, timing and response fields. FRET turns them into temporal formulas, explanations and diagrams. It also has a simulator for trying out signals.
    • number: industrial autopilot case; no large quantified benchmark
    • limits: The translation is checked against the language’s own semantics, not against what the customer meant. Mapping variables to the model is a separate source of error. New users need help with subtle points of meaning.
    • how much was read: most of it read
    • source
    • record id: fret-2020
  • Giskard specification (2020)
    • title: Specification of the Giskard Consensus Protocol
    • what: The paper gives a rigorous executable-style specification of the Giskard consensus protocol used by PlatON, defining nodes, epochs/views, message formats, local/global block stages, state transitions, and fault behavior. It proves three safety properties: same-height prepare blocks in one view are identical; same-height precommit blocks across views are identical; and same-height committed blocks are identical. The proofs reduce quorum intersections and view-change height relationships to contradictions under the one-third Byzantine bound. The specification is intended as an implementation and formal-verification reference, while liveness is left open.
    • limits: The network is partially synchronous and nodes communicate by authenticated broadcast; at most one third of participating nodes are Byzantine. Epoch/view changes can be asynchronous across nodes, and Byzantine behavior includes proposing multiple same-height blocks or voting without required messages. Safety reasoning focuses on message/block stages and does not establish liveness, performance, implementation correctness, or cryptographic assumptions beyond authenticated signatures and quorum behavior. The protocol has ten-block views and VRF-selected epoch participants as modeled in the specification.
    • how much was read: most of it read
    • source
    • record id: giskard-specification-2020
  • Igloo refinement bridge (2020)
    • title: Igloo: Soundly Linking Compositional Refinement and Separation Logic for Distributed System Verification
    • what: Introduces Igloo, an Isabelle/HOL framework connecting compositional event-based distributed-system refinement to code verification in expressive separation logics. Sound refinement and trace inclusion let protocol proofs transfer to heterogeneous Java/Python implementations verified by VeriFast and Nagini. The framework proves composition and translation theorems for event systems, I/O specifications and process implementations. Case studies cover leader election, primary-backup replication and two-party authentication, including fail-stop servers, TCP, UDP, cryptography and unbounded component instances. Isabelle formalizes all definitions/results; code-level abstraction functions connect model states to locked heaps and message bytes.
    • number: Three complete case studies
    • number: Primary-backup proof uses nine invariants for backup consistency
    • number: Java and Python implementations verified with VeriFast/Nagini
    • number: All definitions and results mechanized in Isabelle/HOL
    • limits: Correctness depends on explicit environment/fault assumptions (perfect failure detection, channel guarantees, Dolev–Yao abstraction) and trusted library contracts/parsers. Implementations are manually written Java/Python; extraction is not automatic. Security bitstring cryptography is abstracted through a surjective abstraction function and trusted cryptographic libraries.
    • how much was read: most of it read
    • source; notes: papers
    • record id: igloo-refinement-bridge-2020
  • Leaderless SMR ROLL limits (2020)
    • title: Leaderless State-Machine Replication: Specification, Properties, Limits
    • what: Defines leaderless state-machine replication using possibly cyclic dependency graphs, separates committing from stabilization/execution, and decomposes decision into dependency discovery plus per-command consensus. Claims ROLL tradeoff 2F+f−1≀n between failure tolerance f and fast-quorum size n−F under Reliability, Optimal Latency, Load Balancing. For protocols on its parameter frontier, every chain length k has some failure-free 2-asynchronous run with a live dependency chain of length k. A five-site Google Cloud experiment illustrates EPaxos tail latency increasing with contention, unlike Mencius; proofs in conference paper are sketches with formal treatment deferred. Records graph phases, stable agreement modulo aborted dependencies, batch execution order, DDS visibility/weak agreement, exact ROLL quantifiers, quorum partition proof, skyline examples and chain induction. Separates empirical tail/correlation observations from existential worst-case chains, nice runs from synchrony, decision from execution, and stated abstract properties from a machine-checked implementation. Replaces earlier record that lacked later sections.
    • limits: Fixed n≄2 message-passing processes, fail-stop rather than Byzantine faults, deterministic replicated state machine and unbounded command/log space. Model extends asynchronous wait-free computation with failure detectors; precise detector admissibility/fairness assumptions are deferred to [22]. Do not read Reliability as solving consensus in pure asynchrony without such an assumption. Clients are not modeled; replicas proxy submissions, and different replicas may submit the same command. Conflicts safely overapproximate semantic noncommutativity, considering both final state and response values; relation is symmetric and nonreflexive. Distinct nonconflicting commands may execute in different orders. Classic logs append immutable slots; Generic SMR uses acyclic partial logs with incoming-prefix closure and compatible upper bounds. Safety properties are distinct from termination and real-time/client-response contracts; no complete client refinement proof printed. Leaderless graph maps each command to pending⊄, aborted⊀, or a committed dependency set; phases pending/abort/commit/stable/execute. Aborted commands are removed from dependency sets permanently. A committed command is stable only when no command in its transitive dependency closure remains pending. Stability agrees on stable dependencies globally; conflicting committed commands must have at least one direct dependency between them, allowing cycles rather than a prechosen total order. Algorithm1 executes the largest still-stable subset of a stable command’s closure, in reachability order between components and canonical total order within a cycle. Already executed dependencies need not execute again. Invariant1 excludes an unexecuted dependency outside an earlier batch; Invariant2 says if conflicting c precedes d within a batch then c is in d’s transitive dependencies. It is not simply arbitrary SCC iteration: batch includes eligible dependency predecessors too. Abort pruning, stable-versus-execute status and canonical order must be made explicit in a formal implementation. Theorem1 states Generic SMR reduces to Leaderless SMR without messages, with proof deferred. Direction is an implementation/refinement claim, not equivalence of arbitrary cyclic dependency states with Generic acyclic logs. Ordering all commuting commands to recover Classic SMR would require extra communication. The common dependency graph itself is not yet an agreed total execution log. Algorithm2 calls DDS.announce(c), returning dependency set D or abort⊀ and fast flag b; slow path invokes per-command consensus, then records and broadcasts outcome. Coordinator or a process suspecting it may submit/recover. A nice run has no failures and a perfect failure detector, so only the coordinator calls that command’s consensus. Leaderless does not mean no coordinator: each command has one, with no single primary ordering all commands. DDS Visibility: two conflicting nonaborted announcements include each other in at least one returned set. Weak Agreement: if one announcement of c returns a nonaborted set with fast=true, every other announcement of c returns a nonaborted set; differences contain only commands whose every announcement aborts. Thus raw dependency sets may differ, but aborted differences are removed before stable agreement. Theorem2 claims Algorithm2 correctness, proof in [22]; consensus, detector, and DDS are assumed abstract services, not implemented or verified here. Examples: rotating coordinators preassign order and always use slow flag; Clock-RSM uses timestamps and majority wait, propagates clocks for stabilization; Mencius aborts unannounced prior slots and needs everybody for fast flag; EPaxos example omits sequence numbers, unions observed conflicts, uses spontaneous agreement, and falls back/recovery to a majority; Caesar timestamps and waits/rejects inconsistent higher-timestamp conflicts. These are explanatory decompositions, not verified full protocol implementations or safety audits of recovery rules. Reliability states every submitted command eventually decided at every correct process when at most f failures. This is decision, not by itself a quantitative execution-latency guarantee. Surrounding prose inconsistently says after f failures no progress or less than f; retain the explicit inclusive property. Stable termination of dependency closures and outcomes of submissions by faulty coordinators require the detailed model. Footnote3 discusses reconfiguration/persistent recovery informally, outside the fixed fail-stop proof. Optimal Latency: in every nice run, announce returns after two message delays with nonaborted D containing only previously announced commands; if no concurrent conflicting command, fast flag true. With contention it may be slow-flagged despite two-delay DDS completion, and complete execution may wait arbitrarily longer. Load Balancing: any quorum Q containing coord(c) with |Q|≄n−F can serve its announcement in a nice run. This is freedom of quorum choice, not an empirical guarantee of equal load or geographic latency. Theorem3 ROLL assumes those properties and an available pair of noncommuting commands. Bound 2F+f−1≀n is necessary, not sufficient to construct a protocol. Together with majority-style bounds f,F≀floor((n−1)/2), skyline means no simultaneous parameter improvement. For fixed f the algebra gives quorum q=n−F≄ceil((n+f−1)/2). Do not substitute arbitrary fast-consensus quorums: ROLL quorums must contain that command’s coordinator. Proof sketch assumes violating inequality, partitions P1,P2 of sizeF−1 and Q of size n−2F+2. CAP premise 2F<n gives two coordinators p1,p2 in Q; fast quorums Q1=P1âˆȘQ−p2 and Q2=P2âˆȘQ−p1 have size n−F. Solo nice runs decide empty dependencies. Concurrent run delays cross messages then crashes Q; integer violation implies |Q|≀f. Survivor cannot distinguish carefully spliced runs, forcing empty dependencies for both conflicting commands, contrary to Visibility/Consistency. Detector-history equivalence and eventual stability are essential deferred proof details; the conference sketch invokes Reliability (defined as decision) to obtain stability without fully showing that bridge. Printed consequence that a plain majority fast quorum tolerates at most one failure is not implied by its displayed inequality. For odd n=2m+1, q=m+1 permits f≀2; for even n=2m, q=m+1 permits f≀3, subject also to f≀floor((n−1)/2). Its own n5(F,f)=(2,2) example gives majority q3 with f2, contradicting the unqualified consequence. This is a printed inference conflict, not a demonstrated implementation or refutation of Theorem3. Frontier examples: n5 only(F,f)=(2,2), n7 (2,3),(3,2); EPaxos attains first n7 tuple, Atlas offers(3,1). Paper calls EPaxos/Alvin optimal for n=2f+1, Atlas for f1 and even n or n3. Fast quorum floor(3n/4) for EPaxos needs integer rounding; nearby f+(f+1)/2 notation is unrounded for even f. Table1 rotating-coordinator quorum0 should not be treated as a legal coordinator-containing fast quorum; protocol lacks Optimal Latency and uses no fast DDS path. Table1 marks Caesar as having Optimal Latency, but §7 explicitly says Caesar lacks it because even contention-free commitment may need two round trips. Keep this internal classification conflict rather than certifying either claim from the unread Caesar paper. Table1 has Clock-RSM and rotating coordinator without Optimal Latency, Mencius with it but nonoptimal frontier; EPaxos/Alvin/Atlas with stated frontier conditions. Historical protocol optimality/current best claims are not checked beyond this2020paper. Chain c1
ck means ci∈deps(ci+1), so dependencies run toward the first element. §5.1 defines live as first command not stable at any process; §5 introductory overview instead says last, which is inconsistent. With pending d and deps(a)={b},deps(b)={a,c,d}, chain dba blocks a; c alone stable. A live finite chain does not assert an infinite run, inevitable starvation, or every execution having a long chain. k-asynchrony bounds overlaps: if any message overlaps both first and last messages of a causal message path, path length≀k. Overlap is real-time interval overlap, not Lamport independence of endpoint events. Formal definition is universal over all messages/paths, unlike introductory prose saying existence of a path. 2-asynchronous is not a fixed bound on wall-clock message latency, delay ratio, or clock skew; nice means failure-free/perfect detector, not lock-step synchronous. Theorem4: for every finite k>0, there exists a 2-asynchronous nice run of any ROLL-optimal protocol with live chain sizek. This is a worst-case existence theorem, not a probability distribution, expected latency, or measured percentile bound. Conference statement does not give a numeric command-latency formula in milliseconds or require every command to suffer. Full proof in [22]; conflict-pattern/termination assumptions belong to that detailed model. Chain sketch splits each announcement into request-send S, intermediate M, reply-return R. Induction constructs complete nice σi with no pending messages, chain ci
c1, and interposed Γprime whose paths have size≀1 and whose participating overlap with Qi is Pi of sizef−1. Alternate quorums and indistinguishable coordinator views force next dependency. Truncating final replies makes the chain live. Figure4 gives n5,k7 and quorums{p1,p2,p3}/{p3,p4,p5} with intersection{p3}. Exact general quorum/induction case analysis deferred; sizek need not mean k different replicas. Experiment: Google Cloud, five sites South Carolina, Finland, Canada, Australia, Taiwan (leader),128 closed-loop clients each, no-op service, synthetic key conflicts atρ=0,2,5,10,30percent for EPaxos; Paxos and Mencius baselines. Latency submission-to-execution at steady state, not commit acknowledgment. Each operation picks common key42 with probabilityρ, unique otherwise; ρ is hot-key choice probability, not directly fraction of conflicting random command pairs (under independent choices that pair probability isρÂČ). No-op operations commute semantically, so key conflicts are an intentional safe overapproximation. Figure1 CDF shows EPaxos tails increasing with synthetic contention and Mencius lower median; paper reports latency/batch-size correlation>0.7. No named correlation estimator, sample count, duration, repeated-run uncertainty, machine types, protocol versions, or fault injection specified in this conference paper. No exact quantiles tabulated; graph readings must not be invented. Correlation plus worst-case theorem supports a mechanism, not measured causal attribution of every tail sample or general workload performance. Mitigation discussion: pure writes may return at commit or durable f+1 receipt, but footnote5 requires later reads to wait for all preceding writes to preserve linearizability. Claimed read dependency exclusion assumes cited per-read single-process execution scheme, not arbitrary reads. Waiting for prior announcements can still allow chain of sizen by rotating coordinators, stated without proof here. These are tradeoffs, not new verified algorithms. ROLL Optimal Latency/Load Balancing enforce request-reply form with no pending messages at announcement completion. Weaker latency permitting background messages can sidestep the bound in a fully synchronous model by sharing replies among quorum members. Discussion says partially synchronous version retains ROLL and chaining requires more asynchrony. Thus theorem is relative to its formal properties, not a universal impossibility for every system called leaderless or every weaker fast-path definition. Entire supplied17-page paper now read, including previously missing §§4–8. Theorems1–2 proofs and formal versions of ROLL/chaining deferred to arXiv2008.02512. No machine-checked proof, Verus/Rust/TLA+ specification, LLM involvement, artifact audit, experiment rerun, or independent verification of underlying protocol papers. Citation[4] about dependency-set decomposition names an unrelated local-independent-set approximation paper in bibliography; original intended source cannot be recovered from that reference here.
    • how much was read: most of it read
    • source
    • record id: leaderless-smr-roll-limits-2020
  • Modeling the Raft Distributed Consensus Protocol in LNT (2020)
    • what: # Whole-paper record: Modeling the Raft Distributed Consensus Protocol in LNT (authored by agents unless marked 🧑) Hugues Evrard, MARS 2020, EPTCS 316, pp.15–39, DOI 10.4204/EPTCS.316.2; arXiv 2004.13284v1. Read all 25 PDF pages, §§1–5, the 16 references, complete Annex A model and Annex B skeleton/reliable network. Inspected all 25 rendered pages and read the entire released LNT model and README statically. Exact passages, source lines and PDF/printed pages are in quotes.json and combined.quote-source.txt. No author program, compiler, model checker, prover or solver was run. ## What the paper establishes (authored by agents unless marked 🧑) This is a Raft modeling and experience paper. Its stated goal is “to discuss the process of developing the formal model of a distributed system using LNT” (§1,Q2). The model covers leader election and log replication, separates server and network processes, and illustrates CADP state-space development. It reports a concrete size comparison between reliable and unreliable networks. The complete printed model makes its abstractions inspectable. The paper does not enumerate checked Raft safety/liveness formulas or report their truth values. It gives no parameterized correctness proof or implementation refinement theorem. The abstract attributes Raft correctness to “a manual proof, based on a TLA+ specification” (Q1), and §1 says that proof was presented by the Raft authors (Q2). Thus the LNT model and CADP availability should not be recorded as a new complete Raft verification result. The paper reports two discrepancies in the original TLA+ specification: an unintended prime on matchIndex in AdvanceCommitIndex and a missing candidate-to-follower transition after a same-term leader heartbeat (§3.7,Q20). It says the former “made no practical difference” and the latter “did not impact Raft manual proof.” These are the author’s assessments, not independently checked proof conclusions. The pinned historical TLA+ source credits Evrard for the apostrophe correction (Q55). That pinned snapshot already contains the candidate stepdown branch (Q54); we did not reconstruct the earlier faulty revision. ## Assumptions and represented behavior (authored by agents unless marked 🧑) The configuration fixes the number of servers and bounds terms and total client interactions, “otherwise the state space would be unbounded” (§3.2,Q9). Printed and released defaults are three servers, three terms and three client interactions. The sole measured comparison instead uses two servers, one term and one interaction. Changing server count also requires changing instantiated processes and the array range (§3.3,Q10; Q41–42). The quorum is the strict majority (MaxServerID div 2) + 1 (Q41). The scope is “the core of the protocol, i.e. leader election and log replication”; dynamic membership and log compaction are omitted (§3,Q6). Client actions carry only the leader ID. “We do not need to model client commands, or server responses to clients” (§3.4,Q11). Entries contain only terms (§3.6,Q14; Q44). This cannot establish distinctions between different same-term commands or full service/client response behavior. The network can reorder, drop a message on send, or deliver while retaining a message for duplication (§3.5,Q12–13; Q43). The declared buffer is a set, despite the name msgBag. Identical pending messages collapse to one element. There is no explicit capacity bound or delivery fairness condition. The reliable alternative removes loss and retain-after-delivery branches, but still permits arbitrary message selection and provides no fairness guarantee (Annex B.2,Q40). Its smaller state space supports development under fewer network behaviors. Timeouts are nondeterministic alternatives without elapsed time or randomized duration (§3.6.1,Q15; Q45). At the term bound only the election alternative stops; receiving and other alternatives remain possible. A candidate votes for itself directly, reducing self-message actions relative to the compared TLA+ model. Lower-term messages, including requests, are discarded; the author says this is safe, but supplies no equivalence proof (§3.6.2,Q16). The disrupt branch permits a crash between LNT actions, including midbroadcast (§3.6.4,Q19). It ends in Crash(self), after which the server process terminates; no reboot/recovery transition appears (Q47). This is a process-level crash model, not evidence about interruption at arbitrary implementation instructions. Leaders accept client interactions, append a term entry, and replicate on a later timeout (§3.6.3,Q18). AppendEntries carries zero or one entry, enforced by an assertion (§3.6.2,Q17; Q49). ## Concrete evaluation and cases (authored by agents unless marked 🧑) For two servers, one term and one client interaction, the unreliable network yields 11,862,015 states and 74,821,042 transitions. The reliable network yields 22,311 states and 108,176 transitions (§4.3,Q23–24). Dividing the supplied counts gives about 531.67 times fewer states and 691.66 times fewer transitions. The paper describes the reductions as “three and two orders of magnitude smaller, respectively.” Preserve its wording alongside the exact counts; the computed ratios are reader arithmetic. No timing, hardware, tool release, repeated trials, per-property results or experiment logs are reported for this comparison. The archive contains only README.txt and raft.lnt, with no property files or reproduction script. The downloaded source uses different syntax from the print, including alt/select and card/length; exact textual identity or the exact experimental checkout is not established. A reliable network is a development proxy. The paper says these state spaces “are not relevant for a proper verification” and that an issue found there also appears with the unreliable network (§4.3,Q24). This supports preserving finite bad witnesses under the stated behavioral inclusion, not an unrestricted transfer of liveness or arbitrary formula truth. Figure 1 is a syntax example: two calculator operations, 1+2=3 and 3×4=12, can occur in either order in a four-state/four-transition graph (PDF p.4/printed p.18,Q8). It is not a Raft performance experiment. There are no tables. The DLC/Consul comparison is explicitly attributed to §6 of prior thesis [2]. For 1000 commands and three servers the paper cites 2.3 seconds for DLC versus 0.5 second for Consul, and reports prior interprocess TCP communication under half a millisecond (§4.6,Q28–29). Consul batches commands while DLC sends a round for each command, so this is not an isolated measurement of formal-method overhead. The thesis and implementation were not independently evaluated here. ## Static discrepancies requiring care (authored by agents unless marked 🧑) Three local source cases qualify use of the model as a reference specification. All appear both in the visually inspected appendix and released LNT source. These are reader-created symbolic valuations; no reachable execution or protocol safety violation has been established. - Same-term candidate: reception sets Follower only when mTerm > currentTerm; the AppendEntries handler receives no state argument. A Candidate at term 1 processing a valid term 1 empty heartbeat remains Candidate (Annex A.5/A.6.3,Q35–36; released source Q46/Q49). This disagrees with the paper’s Raft overview that “other candidates step down to the follower state” (§2.2,Q4), and resembles the upstream omission discussed in §3.7. It does not establish that the earlier TLA+ defect causes a safety failure. - Failed replication response: nextIndex[mFrom] := max(1 of nat, nextIndex[mFrom]) has no decrement. A local value 3 stays 3 (Annex A.6.4,Q37; Q50). This disagrees with the §2.3 description that the leader retries “with a lower index” (Q5). We have not established a reachable failed replication trace or measured its effect. - Follower commit assignment: commitIndex := mLeaderCommit lacks a cap by local log length or a monotonic guard. With a locally empty log, previous index 0, empty entries and leader commit 1, the handler leaves an empty log with commitIndex 1 (Q36/Q49). Reachability is unknown. The pinned TLA+ source also directly assigns the leader index and says an old duplicate request can decrease it (Q54). This may be an inherited abstraction; do not label it a newly discovered LNT safety bug. The symbolic cases are retained in static-witnesses.json. Their purpose is to distinguish the source’s actual expressions from the prose and from unproven invariants, not to substitute for model checking. ## What this adds to the research topic (authored by agents unless marked 🧑) The paper contributes an explicit distributed consensus model, reusable network/node structure, evidence that network assumptions strongly affect state-space size, and a concrete account of translation exposing specification discrepancies. It also explains the gap between a model and implementation: the Distributed LNT Compiler generates C but its synchronization protocol assumes reliable interprocess communication (§4.6,Q28). Discussion of Verdi is attribution to related work, not an implementation correctness result from this paper. The state-space advice is qualified. Fixed broadcast order is justified informally by arbitrary receive order. The author warns that removed paths may be “irrelevant to a given verification property, but crucial to an other” (§4.4,Q26). Bypassing duplication or outdated messages is proposed as future work requiring “formal verification or proof” (§4.5,Q27), rather than a proved reduction method. For evaluating LLM-written specifications and proofs, the reader-derived lesson is to inspect the represented state, bounds, message semantics, source/prose agreement, property statements and implementation link separately. The three static cases show why a plausible protocol narrative and a formal-language artifact do not by themselves establish the intended transitions. The paper supplies no Verus, verified Rust or LLM experiment.
    • limits: Fixed finite servers, bounded terms and total client interactions; defaults3/3/3 versus measured2/1/1. Core election/replication only, term-only entries and leader-ID client actions. Finite-set network reorders/drops/duplicates without capacity or fairness guarantee. Nondeterministic untimed timeouts, crash termination without recovery. Informal reductions and source/prose discrepancies qualify reference-model use.
    • how much was read: most of it read
    • source
    • record id: modeling-the-raft-distributed-2020
  • NetSMC: A Custom Symbolic Model Checker for Stateful Network Verification (2020)
    • what: NetSMC checks temporal policies on models of stateful network functions with persistent tables and one packet traversing the network at a time. It translates a restricted LTL language into CTL and represents sets of network states as existential first-order formulas. Backward preimages and a containment algorithm adapted from database query containment avoid general solver costs. A packet-order argument gives equivalence to interleaved executions for selected policies under an order-preservation condition. Benchmarks compare VMN, a Z3 containment variant, NuSMV and Cubicle; author-run exercises inject configuration mistakes into real network functions. Records exact NF/packet transition semantics, commutation and order-preservation conditions, restricted temporal operators and full appendix proofs, EFO preimage and containment construction, proof/implementation boundaries, printed listing/formula concerns, every Table2 timing and the narrow scopes of speedup, planted faults and model fidelity.
    • limits: §§4/8: A fixed topology and NF rule set; packets contain modeled header/application fields, not arbitrary payload processing. State is a collection of finite key-value maps; tests use specified finite domains, updates assign modeled expressions or increment/decrement by constants, expressions may choose nondeterministically from a domain. No multicast/broadcast, averages, generic computations, clocks/timeouts or direct network failures. Failures require separate enumerated scenarios. Integer/counter bounds and overflow semantics are not developed into an implementation-level finite-state proof. §§4.1/4.3/AppendixA: Exactly one matching NF rule; sequential commands are atomic at NF network-step granularity. A link preserves packet and tables. Drop/Exit permits an arbitrary next packet at arbitrary ingress, retaining all tables. Correct rules/topology/initial tables/model extraction are trusted; sequential packets do not mean tables reset between packets. Nondeterministic backend choice abstracts a concrete policy rather than verifies its implementation. §4.3/AppendixC: Every packet eventually leaves or drops; transient loops allowed, indefinite loops excluded. Unique immutable IDs distinguish packets. Interleaved model buffers unordered sets, not FIFO queues, and proof considers finite closed traces with no unfinished nonterminal packets. No general liveness/fairness or live controller-update verification. AppendixC/Definitions4–5/Lemma1: Non-conflict means swapping two same-NF processing steps preserves both output packets and final table valuation for every relevant initial valuation. A strict total packet order must be respected wherever packets conflict. Adjacent inversion swaps decrease an out-of-order index until packets can be serialized with identical per-packet located-packet traces. Conditions are assumptions on networks; no checker that establishes them for arbitrary input models is evaluated. §5/AppendicesB/D: Policies universally quantify outer variables; basic predicates inspect fields/location/tables. Permitted temporal forms are basic, F basic, within-packet eventual f basic, X(guard→formula), G(guard→formula), and within-packet g(guard→formula). f/g expand to restricted strong-until formulas terminated by Drop/Exit. General until, arbitrary quantifier alternation, generic temporal nesting/past properties excluded. A positive answer for arbitrary policies under serialization does not establish concurrent correctness. §5/AppendixD/Theorem7/Corollaries2,8: Conditional equivalence explicitly covers isolation, tag preservation and tag-based isolation on order-preserving networks. Other policies such as flow affinity/NAT consistency/service chaining are checked under the one-packet model and may miss interleaving bugs. Do not read Table1 sound/conditionally-complete labels as unconditional verification of all concurrent deployments. AppendixD qualified proof-scope concern: Theorem7 syntactically uses basic guards without explicitly excluding table predicates, although Lemma1 preserves only located-packet input/output traces, not every intermediate table valuation while a packet waits. Reordered unrelated processing can alter such valuations. The printed transfer argument therefore needs a restriction to predicates determined by those traces or an additional preservation proof; isolation/tag examples avoid this issue. This is a reading concern, not an executed counterexample against the tool. §6.2: EFO state formulas are disjunctions of conjunctive clauses with membership, inequality, location/field equality and table lookup. Variables are existential and outermost; denotation is a set of concrete packet/table valuations. This is a symbolic representation, not sampling of packet histories. §6.3/Algorithms1–2: Preimage unions NF-rule, link and new-packet predecessors. Commands processed in reverse order; tests conjoined. New-packet transition drops successor field/location constraints but preserves their variable/table relationships, restricts successor ingress and predecessor Drop/Exit. Table updates split equal-index overwritten entry versus an unequal index retaining old value. Helper expression translation F and link routine are omitted; precise implementation behavior is not reconstructed from pseudocode alone. §6.4/Algorithm3: Interpret clauses as conjunctive queries; homomorphism maps variables of candidate containing clause into contained clause. Inequalities require splitting equality patterns into atomic clauses; finite domains need emptiness checks (e.g., singleton variables forcing incompatible table values). Every nonempty atomic clause must map to some disjunct of target. This avoids a naive implication query to Z3, while still potentially expanding many clauses. §6.4/Theorem3 and AppendixE: Authors state exact True iff satisfaction under one-packet semantics. Appendices provide detailed semantics, trace reordering, policy transfer and structural LTL→CTL arguments (Theorem9/Lemmas10–12); no separate complete proof of Algorithm1/2 preimages, Algorithm3 domain splitting/emptiness, or Python refinement appears. Theorem3 is not a machine-checked verified implementation. Algorithm2/p188 printed-listing concerns: loop binds ÎČ_j on line14 but line15 passes ÎČ_i, and line21 recursive COMPUTECLS call omits expression-environment arguments present in its signature. Figure11/p196 sequence rule leaves c2 as a pending command without giving the corresponding continuation rule in the displayed semantics. Treat as incomplete/inconsistent presentation; no artifact tested. AppendixF/p200 printed-policy concerns: NAT consistency formula contains p without the displayed outer binder (only ∀i), despite closed-formula requirement. Flow affinity shown for S1 needs analogous instances for other servers. Conditional reachability uses G(loc=B→f(loc=A)) from the same arrival state at B, so without distinguishing request arrival from new reply injection it can demand that the current packet return to A; the prose speaks of packets sent afterwards. Qualified formula/specification boundary, not a measured tool failure. §7: Python prototype,20core2.8GHz/128GB server. CPU model/OS/Python/solver versions, source LOC, repeated-run statistics, confidence intervals and memory usage not reported. Alembic-generated NF models and manual POX translation used; authors assert high fidelity, but no formal extraction/refinement theorem or measured model-fidelity error rate is provided. §7.1/Figures6–8: Synthetic host/rule scaling and extended fattree/Ai3/Sprint topology isolation checks; flow-space sliced for both tools. Specific speedups depend on policy/model and baseline. VMN lacks service-chain policy support, so policy-complexity comparison uses only NetSMC/Z3. NuSMV fixed16-entry table and NetSMC without that size constraint are different encodings; Cubicle750× lacks detailed absolute timing/setup in text. §7.2: Red team authors2/3 inject secret deleted/modified rules; blue team author1 diagnoses with NetSMC, then rechecks fixed model. Four described real-NF exercises and nine modeled Table2 scenarios all succeed as reported; no production-discovered fault count, exhaustive fault set, detection rate, false-positive rate or independent user study. All benchmark/tool outcomes here are authors reports, not reproduced.
    • how much was read: most of it read
    • source
    • record id: netsmc-a-custom-symbolic-2020
  • Quartz (2020)
    • title: Quartz: A Framework for Engineering Secure Smart Contracts
    • what: Quartz is a DSL for smart contracts written as extended state machines. It generates PlusCal/TLA+ for TLC, including Ethereum exceptions and reentrancy. It also generates Solidity. The author writes the invariants.
    • number: 16 contract case studies
    • number: auction 33 DSL / 40 handwritten Solidity / 53 generated / 205 TLA+ lines
    • number: mean DSL/handwritten ratio 0.68
    • number: auction bugs found in 2, 6, 15 seconds; ERC-1540 in 4 and 27 minutes
    • limits: It covers finite, bounded safety only. Nothing proves that the generated Solidity matches the TLA+. No author hours are given.
    • how much was read: most of it read
    • source; notes: Quartz: A Framework for Engineering Secure Smart Contracts
    • record id: quartz-2020
  • SCP proofs (2020)
    • title: On the Formal Verification of the Stellar Consensus Protocol
    • what: A first-order model of SCP quorums and balloting in Ivy/Z3. It proves agreement, and proves termination for intact sets under eventual synchrony. Isabelle proves the abstraction sound.
    • number: no person-hours, proof-line total or timing reported
    • limits: It is a protocol model for fixed configurations, not deployed code. Membership cannot change dynamically. The short paper omits detailed proofs.
    • how much was read: most of it read
    • source; notes: Related addition: On the Formal Verification of the Stellar Consensus
    • record id: scp-proofs-2020
  • VeriBetrKV (2020)
  • Zhang SPA TLA+ workflows (2020)
    • title: Specifying and Model Checking Workflows of Single Page Applications with TLA+
    • what: Presents a TLA+ modeling pattern for single-page application workflows: variables represent observable widget properties and actions represent user events; TLC checks reachability, liveness, invariants, and deadlock. The paper gives a complete math-exercise SPA module with Init, Input Answer, Check, New Question, Terminating, and weak fairness, then demonstrates diagnostic TLC results. Reachability of every question and eventual availability of New Question are proved; an initially plausible invariant is falsified and repaired to condition on a nonempty result; an off-by-one precondition creates a concrete deadlock. The mapping is deliberately practice-oriented and exposes implicit widget-state workflows.
    • number: one clock example
    • number: one math SPA case
    • number: three user actions plus Terminating
    • number: finite-state TLC analysis
    • limits: The case study is a small finite-state model with a bounded maximum question count and nondeterministic answer correctness; weak fairness is used to prevent stuttering. It models user-observable widget states rather than implementation code, omits asynchronous communication and server activity, and does not evaluate an industrial SPA. The author notes TLC’s finite-state limitation and proposes theorem proving and automatic AngularJS-to-TLA+ generation as future work.
    • how much was read: most of it read
    • record id: zhang-spa-tla-workflows-2020
  • ByMC Blockchain BFT Verification (2019)
    • title: Formal Verification of Blockchain Byzantine Fault Tolerance
    • what: Surveys blockchain-consensus vulnerabilities and formally verifies two Red Belly Blockchain components with the ByMC threshold-automata model checker: binary-value broadcast and a DBFT-style Byzantine consensus variant. The authors provide executable threshold-automaton specifications and temporal properties for safety, validity, agreement, and termination. The paper explains the manual conversion from pseudocode to threshold automata, including shared counters, guards, fairness assumptions, and counterexample debugging. BV-broadcast uses n>3t asynchronous reliable channels and four correctness properties; its 116-line specification verifies in under 40 seconds on a laptop. The larger consensus automaton models two asynchronous rounds and is checked under round-rigidity/fairness with MPI; five properties sum to 1046 seconds. The paper stresses that formal verification covers specified automata, not implementation correctness, and reports six blockchain vulnerabilities including new Casper FFG and HoneyBadger counterexamples.
    • number: BV-broadcast specification 116 lines, verified in <40 s on Intel Core i5-7200U
    • number: consensus specification 276 lines, five properties in 1046 s (17 min 26 s)
    • number: model checker uses MPI on 4×16-core AMD Opteron 6276 with 64 GB
    • number: ByMC verification of properties over reachable threshold-automaton states
    • limits: Threshold-automata abstraction assumes parameterized Byzantine bounds (N>3T, T≄F≄1), reliable channels and asynchronous scheduling; liveness requires fairness/round-rigidity assumptions. Manual translation can contain errors, and verified properties do not guarantee the blockchain implementation or other execution tools are correct. The large run uses a 64-core AMD Opteron machine and is not a proof of scalability to arbitrary deployments.
    • how much was read: most of it read
    • record id: bymc-blockchain-bft-verification-2019
  • Coq financial-market auctions (2019)
    • title: Formal verification of trading in financial markets
    • what: Defines a Coq framework for bids, asks, matchings, fairness, maximality, uniformity and individual rationality, then verifies dynamic-price and uniform-price double-sided auction algorithms. The formalization models lists of unit bids and asks with dependent records and computable predicates. It proves existence of fair matchings and maximum matchings, constructs a dynamic-price algorithm and proves fairness/maximality, then constructs a uniform-price algorithm and proves that it is maximal among uniform matchings. The text includes a concrete counterexample where the uniform algorithm is not maximum in cardinality, clarifying the distinction between uniformity and global maximum matching.
    • number: two auction classes: dynamic-price and uniform-price
    • number: Theorem 17 fair matching existence
    • number: Theorem 18 maximum matching result
    • number: Theorem 20 maximality among uniform matchings
    • limits: The market model treats each bid or ask as a request for one unit and reasons over finite lists with no duplicate constraints where stated. Results are about the formalized matching algorithms and properties, not exchange implementation throughput, networking, or adversarial distributed execution. The paper reports no empirical benchmark; correctness is established in Coq without added axioms.
    • how much was read: most of it read
    • record id: coq-financial-market-auctions-2019
  • Deconstructing Stellar Consensus (Extended Version) (2019)
    • what: # Reading: Deconstructing Stellar Consensus (Extended Version) (authored by agents unless marked 🧑) GarcĂ­a-PĂ©rez and Schett’s arXiv 1911.05145 v3 (13 December 2019) gives a mathematical account of Stellar’s ballot protocol. Its main construction separates federated voting, an idealized abstract consensus protocol and a concrete protocol that compresses voting statements. Read all 43 pages, eight main sections, Appendices A–E, four algorithms, four figures, all numbered arguments and 16 references. The paper has five theorem statements, four corollaries and 44 lemmas. All 43 page renders inspected through 11 contacts; pages 5, 12, 23, 29, 30, 33, 36 and 37 individually. The paper supplies mathematical proofs and illustrative executions, not a mechanically checked development or an evaluation of deployed Stellar code. The model fixes a finite universe V. A correct node follows the protocol; an honest node may additionally stop; a malicious node may deviate otherwise. Every pair has an authenticated perfect link. Partial synchrony provides a finite unknown GST after which message delays are bounded; correct timers have bounded disagreement over a given delay after GST. Trust configuration is an input to the proofs. Open membership motivates federated quorums, but this model does not prove dynamic membership changes, trust-list discovery or correctness of a complete blockchain (§§1–2). A federated Byzantine quorum system (FBQS) assigns each node a nonempty family of slices, each containing that node. A nonempty set is a quorum if every member has a slice wholly within it. Two correct nodes are intertwined when any quorum containing the first intersects any quorum containing the second in a correct node. An intact set I is itself a quorum and its projection has the required intersection between its members. Lemma 3 gives intersection inside I for any two quorums that touch I; Lemma 4 makes intersecting intact sets merge, hence distinct maximal intact sets are disjoint. Agreement is local to an intact set. The four-node Example 2 with faulty v3 has maximal intact sets {v1,v2} and {v4}; the two sets can disagree. In contrast, the classical 3f+1 construction with 2f+1 slices and at most f faults has all correct nodes in one maximal intact set (§2; Appendix A). The specification requires output once, agreement within each maximal intact set, and weak validity conditional on every node being honest. Under that condition, unanimous proposals force their value and any decided value must have some proposer. It does not require a correct proposer when malicious nodes exist. Its liveness condition is non-blocking: from any prefix, an undecided intact node eventually decides in every admissible continuation where all malicious nodes stop. The authors explicitly say that continuing malicious traffic with good timing can delay termination permanently for their chosen timeout strategy. Thus this is not unconditional Byzantine termination. Section 3’s subsequent broad sentence about entailing usual weak consensus in 3f+1 systems, and its phrase “if every correct node is honest,” need that earlier condition retained: correctness already entails honesty, and cardinality quorum intersection alone does not remove the continuing-malicious-traffic case (§3, pp4–5). Federated voting (FV) is a tagged Bracha-style primitive. A node first sends VOTE(a); a quorum containing the recipient enables READY(a); a set intersecting every one of that recipient’s slices also enables READY(a); a quorum containing the recipient enables delivery. Those slice-intersecting sets are called v-blocking. Each intact node’s blocking set touches I. Therefore its first READY for a value is justified by a quorum, preventing conflicting READY values inside I. Theorem 6 proves no duplicate deliveries, totality inside I, consistency for intertwined nodes and delivery when all nodes in I vote alike. A finite propagation argument yields an unknown bounded post-GST delivery delay ÎŽ_I once one node in I has delivered. FV alone does not guarantee a decision from arbitrary split votes (§4; Appendix B). The condition that the recipient belong to the supporting quorum is essential. In Example 2, {v3} is a quorum. If v3 is malicious and the recipient-membership condition is removed, it can send different READY values to v1 and v2 and make these intact peers deliver differently. Figure 1 gives a separate benign voting pattern over four classical nodes: two correct nodes vote false, one votes true and the malicious node helps false. The last correct node changes from its VOTE(true) to READY(false) after a blocking set persuades it. Changing a readiness value relative to one’s vote is intended behavior, rather than equivocation (§4, Figure 1, Example 8). The abstract SCP (ASCP) uses ballots (n,x), ordered first by positive round n and then totally ordered value x, plus a null ballot. It runs a Boolean FV instance for each ballot. Voting false aborts that ballot; voting true tries to commit it. To prepare b, a node delivers false for every lower ballot carrying a different value. It may then raise its candidate to the prepared ballot and vote true. Committing b decides x and stops the node. Safety combines Lemma 9, that a committed ballot had an intact preparer, with Lemma 10, that preparing a higher incompatible ballot excludes an intact READY-to-commit for a lower one. Lemma 11 tracks a largest prepared value back to some proposal when all nodes are honest. Ready-trees, whose leaves are voting quorums, support this validity argument (Algorithm 2; §§5 and Appendix C). ASCP is an idealization: it allocates infinitely many FV states and can process infinitely many ballot messages in one step. Batched network semantics sends possibly infinite sequences atomically and processes an entire received batch atomically in ballot order. These semantics do substantive proof work; they are not a measured implementation optimization. A formalization must specify admissible ordered sequences and existence of the maxima used by later definitions; a bare totally ordered value domain does not by itself provide every enumeration or maximum. The paper abstracts from Stellar’s nomination protocol and assumes arbitrary consensus proposals, so its result covers the ballot protocol, not nomination, transaction validation or a ledger implementation (§5, including footnote 1). A quorum of messages endorsing higher rounds starts or restarts a timer with delay F(round). A timeout advances to the next round, retaining the largest prepared value if any, otherwise the candidate’s value. F doubles with the round. The liveness proof defines a round’s prepare-footprint as contributing voting-quorum leaves, its abort interval as their sending interval, and its window as ÎŽ_I after the first intact preparation. Lemma 12 claims that sufficiently late windows stop overlapping when faulty nodes stop. Corollary 29 then synchronizes the largest prepared ballot across I; Theorem 13 concludes the peers either commit it or advance together with its value. Figure 2 depicts the required inequality F(n) > ÎŽ_A(n)+ÎŽ_P+ÎŽ_I. A machine proof must bound the round-dependent abort interval and justify eventual domination and persistence of this inequality; doubling F alone does not establish those steps. No numerical termination bound is supplied (§5; Appendix C, pp22–24). Concrete SCP (CSCP) replaces the infinite FV array with one bunched-voting (BV) process. A prepare statement for b summarizes aborting all lower incompatible ballots; a commit statement names b. BV stores the highest ballots voted, readied and delivered for a prepare statement, plus sets of ballots voted, readied and delivered for commit. A node votes prepare only as its maximum rises; commit voting additionally requires b to equal its maximum voted prepare. Quorum and blocking conditions combine prepare statements by inclusion of the lower-incompatible sets. Algorithm 4 keeps the abstract candidate/prepared/round logic and replaces Boolean FV calls with prepare/commit indications. State is finite at each finite execution prefix; the growing ballot numbers and commit sets are not a fixed finite-state bound (§6, Algorithms 3–4). The printed Algorithm 3 has a material guard mismatch. Line 8 checks max-voted-prep < b, whereas the surrounding explanation and the corresponding Appendix D proof use max-readied-prep < b. The statement in the prose describing lower-incompatible inclusion also reverses its direction relative to the displayed formula. A hand case exposes the guard consequence: use four correct nodes with classical three-node quorums, values {0,1}, and unanimous proposals 0. After all invoke prepare((1,0)), their maximum voted prepare is (1,0); the greatest ballot justified by those matching VOTE messages is also (1,0), so the printed strict guard rejects it. With no READY messages, the blocking rule cannot start. In a lockstep execution, timeouts make every node prepare((r,0)) before that round’s votes arrive, repeating the same rejected equality each round despite timely delivery. This identifies behavior of the literal displayed guard; it does not refute the intended max-readied-prep version. The paper’s own Figure 4 readiness steps also require the intended version (Algorithm 3, p12; §6, p13; Appendix D, p33). Theorem 14 claims observational refinement: every CSCP execution has an ASCP execution with the same proposal/decision history projected to I. Appendix D defines a simulation σ that expands prepare statements into abort batches, commit messages into true-voting batches, and preserves external events. It proves candidate/prepared/round agreement and several voting-state invariants, then checks all concrete event cases. Lemma 37 handles finite prefixes; the theorem extends to complete traces. These are paper proofs, not a simulation run or proof-tool output (§6; Appendix D). Several simulation details need explicit repair or justification before mechanization. Definition 31’s φ is a maximum over ballots whose lower incompatible ballots have delivered false, and its commit expansion uses φ(σ(τ)) < bâ€Č ≀ b. One must fix the implicit node parameter, establish that the maximum exists, and explain which pre- or post-preparation cutoff includes the true votes generated during preparation. Lemma 33 states a readied commit ballot is at most max-delivered-prep, but Lemma 35 invokes it as a bound by max-readied-prep; the statement and use need reconciliation. The READY(cmt) cases in Lemma 37 assume b > max-readied-prep, a guard not present in Algorithm 3’s commit-readiness rules. Receiving a message at a correct recipient also does not by itself rule out contradictory earlier messages from a malicious sender. These are identified proof/encoding obligations, not completed disagreement executions (Appendix D, pp29–35). The step from finite prefixes to complete traces and the transfer of conditional properties require more than proposal/decision equality. A fair infinite concrete run must map to an admissible fair abstract run with the relevant timing and stopped-malicious-node conditions. Otherwise every finite prefix could be legal while the infinite execution starves an enabled action. Likewise, weak validity’s all-honest premise must survive the construction of abstract behavior outside I, whose external proposals are absent from I’s history. Corollary 15 cites history equality to transfer all four properties without separately spelling out these premise-preservation arguments. This reading records the claimed refinement and non-blocking result while leaving those obligations open; it supplies no general refutation of SCP (§6; Appendix D, p36). The authors illustrate matching abstract/concrete histories in Figures 3 and 4 with correct proposals 3, 3 and 1. Nodes first prepare (1,1), then prepare (1,2) with malicious support, fail to gather a commit quorum, timeout, then commit (2,2) and decide 2. The displayed concrete trace is inconsistent with Algorithm 3: besides the already identified READY-prep guard mismatch, v4 votes commit((1,2)) without ever voting prepare((1,2)). Its max-voted-prep remains (1,1), so the line-18 commit guard rejects that vote even after fixing line 8. This is an author illustration, not a certified literal execution of the printed pseudocode; the local mismatch does not by itself establish disagreement or refute the repaired protocol. No correct node proposed 2, which is permitted by the stated validity under malicious behavior. The abstract execution expands an infinite abort batch when entering round two; the concrete one represents it with one prepare statement. These are worked executions, not empirical benchmark results (Appendices C–D, Examples 30 and 38). Subjective FBQS permits each correct node to have its own view of malicious nodes’ slices, while all correct-node slices agree across views. The intact sets coincide across these views (Lemma 16); any two known quorums touching I intersect inside I (Lemma 17). These facts lift FV, ASCP and the refinement to that setting, yielding Theorems 18–19 and Corollary 20. Appendix E gives the lifted lemmas and analogous proofs. It does not allow correct nodes to disagree arbitrarily about each other’s slices, nor does it prove that a real trust configuration contains an intact set. The self-reference in Lemma 50’s proof is a visible citation error; its intended non-subjective precursor is Lemma 11 (§7; Appendix E). There are no measured performance results, production-code equivalence claim backed by an artifact, test statistics, TLA+ model, verified Rust/Verus development or LLM-agent experiment in this edition. Its contribution to distributed verification is the explicit guarantee boundary around intact sets, reusable voting lemmas and a concrete-to-abstract proof structure. The guard mismatch, assumption-preserving refinement and finite-prefix/fairness distinctions are concrete cases for evaluating specification/proof agents; that use is a reader inference. No author code, compiler, checker, solver, prover, model checker or scientific-result artifact was executed or loaded. Hand cases above are source reasoning only.
    • limits: fixed finite universe, authenticated perfect links, eventual bounded message delay/timer disagreement; intact-set local agreement; weak validity all-honest; malicious stopping for non-blocking; infinite atomic batches in abstract model; intended concrete guard differs from print; assumption/fairness-preserving refinement obligations
    • how much was read: most of it read
    • source
    • record id: deconstructing-stellar-consensus-extended-2019
  • Dijkstra Monads for All (2019)
    • what: Generalizes the construction so that one executable model of an effect can have several logical specifications (for example, exceptions allowed or forbidden). Has examples in F* and Coq.
    • number: no benchmark rate, timing or proof size reported
    • number: No benchmark rate, solving time, proof lines or human effort reported
    • number: Pythagorean search example picks triples from the list 1 through 10 (§3.4)
    • limits: F* did not implement the proposed specification metalanguage. The Coq version omits the linear type system and assumes a semantic condition.
    • how much was read: most of it read
    • source; notes: Dijkstra Monads for All; notes: Dijkstra Monads for All; notes: Concrete problem records
    • record id: dijkstra-monads-for-all-2019
  • IBFT 2.0 (2019)
    • title: IBFT 2.0: A Safe and Live Variation of the IBFT Blockchain Consensus Protocol for Eventually Synchronous Networks
    • what: Defines the IBFT 2.0 proof-of-authority BFT protocol with immediate finality, dynamic validator sets, and eventual-synchrony robustness. It gives pseudocode and a high-level lemma-based proof of optimal safety, persistence, weak liveness, and (with a fair-network probability assumption) liveness for up to floor((n−1)/3) Byzantine validators. The protocol removes IBFT locking and relies on prepared certificates, round-change certificates, and quorum commit seals. Height-tagged messages make lagging nodes request missing finalized blocks, addressing persistence. Safety derives from quorum intersections and induction over rounds (Lemmas 1–7); weak liveness derives from exponential round timers and eventual synchrony (Lemmas 8–17). Full liveness additionally assumes every sent message has positive probability of delivery within one-third of the initial timeout, then uses round-robin proposer selection and stable validator windows (Lemmas 18–23). The paper proposes ten concrete improvements, including fair proposer selection to remove the probabilistic assumption, two-phase fast path, quorum-triggered round advancement, hash certificates, reduced signatures, and aggregate signatures.
    • number: f(n)=floor((n−1)/3)
    • number: Quorum(n)=ceil(2n/3)
    • number: 4Δ synchrony window in Lemma 16
    • number: two-phase fast path claims 33% latency reduction
    • limits: Eventually synchronous gossip after GST with fixed delay Δ; cryptographic hash collision resistance and signature uniqueness/unforgeability; at most floor((n−1)/3) Byzantine validators per height; honest chains agree through h−1. Liveness (as distinct from weak liveness) depends on Fair Network Behaviour Assumption unless FairProposer is adopted. Formal specification and implementation details are explicitly future work; validator voting pseudocode is omitted.
    • how much was read: most of it read
    • record id: ibft-2-0-2019
  • Moderately Complex Paxos Made Simple: High-Level Executable Specification of Distributed Algorithms (2019)
    • what: Rewrites Multi-Paxos pseudocode as a short executable specification in DistAlgo, translates it by hand to TLA+, and proves safety in TLAPS. It also finds liveness defects when messages are lost.
    • number: DistAlgo core 51 vs 142 pseudocode lines
    • number: TLA+ models 154, 157, 217 lines; proofs 4,959, 5,005, 7,006 lines
    • number: TLAPS obligations 4,364, 4,517, 5,580; 590, 569, 781 s on i7-4720HQ
    • number: 77.822 ms per request with 10 processes
    • limits: The proof covers the hand-translated models. There is no proof that the translation is correct. The liveness defects are only discussed. The manual effort is not given.
    • how much was read: most of it read
    • source; notes: Moderately Complex Paxos Made Simple: High-Level Executable Specificat
    • record id: moderately-complex-paxos-made-2019
  • On the parallels between Paxos and Raft, and how to port optimizations (2019)
    • what: # Reading: porting Paxos optimizations to Raft* (authored by agents unless marked 🧑) Wang, Zhao, Mu, Chen and Li study a modified Raft called Raft*, not a proof that original Raft and Paxos are interchangeable. The whole 61-page extended paper, Appendices A–C, six printed TLA+ modules, 15 figures and 67 references were read. Exact supporting passages are staged in quotes.json with section and PDF-page anchors. The central construction starts with already-correct specifications A, its optimization AΔ, and B refining A. A non-mutating optimization introduces state/actions or conjuncts without changing A’s existing state updates. Given state and action-parameter mappings, translating the added clauses produces BΔ. Section 4.3 sketches BΔ refining both AΔ and B, preserving their invariants. This is a conditional specification transformation, not a general liveness or performance theorem. Added guards can prevent progress; added actions must explicitly preserve old state, and initialization and new-variable frames must be compatible. The paper leaves implementation to developers and states in §1 that correctness is guaranteed only at specification level. Raft* prevents deletion of accepted entries by returning extra log entries during elections, selecting safe suffix values, and rejecting shorter appends. A separate accepted-ballot field distinguishes an entry’s original Raft term from its latest Paxos acceptance ballot. Figure 3 maps leader self-acceptance as well as explicit messages. One Raft* action can cover multiple Paxos operations, so porting must account for every relevant action, including implicit self-acceptance. The two implemented cases are quorum leases (PQL) and Mencius. PQL allows a leaseholder to read locally only after relevant pending writes are applied; writes notify the leaseholders of an intersecting quorum. Translating f+1 Paxos acknowledgments to f remote Raft acknowledgments must include the leader’s implicit acknowledgment and its own leaseholders. The authors describe a handwritten version that omitted those leaseholders. Mencius assigns default log-slot proposers round-robin. Nondefault recovery proposes no-ops; skipTags allow default no-ops to become executable early. The optimization must be applied to every action corresponding to Paxos acceptance, including BecomeLeader and AppendEntries, not only ReceiveAppend. Appendix B abstracts leases with one global timer; distributed-clock and real lease-expiry correctness require additional implementation assumptions. Evaluation uses five AWS regions (Oregon, Ohio, Ireland, Canada, Seoul), two m4.xlarge instances per region for client/server, 4 vCPUs, 16 GB RAM, SSD and stated 750 Mbps network. WAN latency spans 25–292 ms. Closed-loop YCSB-like workloads use 100,000 keys, a configurable shared hot-key probability and otherwise region-partitioned uniform keys. Each trial lasts 50 seconds with a stated 10 seconds for warm-up and cool-down; whether 10 seconds applies jointly or separately is unclear. Results are medians of five trials. Implementation builds on etcd c4fc8c09, retaining custom networking/batched forwarding that the authors say improves throughput 2.4×. Oregon is the favorable Raft leader placement. PQL uses 2-second leases, renewal every 0.5 seconds, default 90% reads and 5% conflict, and 50 clients per region for latency. About 90% of reads take 1 ms; leader-lease leader reads take 1.6 ms, while a 1% follower tail reaches approximately 137 ms from conflicting writes. PQL reports 1.6× throughput at 90% reads and 1.9× at 99%; write latency rises because leaseholders must acknowledge. Figure 9(d)’s x-axis runs from 50% conflict on the left to 0% on the right. Its rising speedup therefore agrees with the prose that lower conflict helps. An earlier apparent contradiction came from overlooking that reversed axis and is withdrawn. Figure 9 captions/legends use Raft where parts of the prose discuss Raft*; keep that baseline wording distinction. Mencius uses 100% puts, 0% or 100% conflict, and 8-byte or 4-KB payloads. The CPU case reaches about 55,000 versus 41,000 operations/s (about 1.34×); the network case reports 70% higher throughput than Raft-Oregon. Oregon itself beats Seoul by 30% in the stated comparison. Execution can still wait for remote earlier slots: the paper reports roughly 360 ms versus 110 ms for Mencius conflict/no-conflict cases, and about 79 ms at the Raft-Oregon leader. These are workload/deployment measurements, not a verification result, fault campaign, or universal optimization guarantee. The paper claims a machine-checkable TLAPS refinement proof in §6. Appendix C is a manual prose proof outline, and Appendix B supplies specifications and invariant statements, not executable TLAPS proof bodies. The referenced GitHub master-tree request and, after waiting over five minutes, repository metadata endpoint returned HTTP 404 on 19 October 2026 UTC. No external proof source was recovered; artifact-acquisition.json records the later response. A missing retrieval does not disprove that a historical proof existed. Appendix C calls a batch-to-sequence correspondence ‘stuttering’, although true stuttering leaves the mapped abstract state unchanged. Its one-step simulation statement needs an abstract batch action or a justified intermediate-state argument. Its BecomeLeader safe-prefix/suffix claims are asserted without derivation in this outline. Its mapping table also uses lastLogEntry.Term where the main text distinguishes the accepted ballot. Several printed specifications require repair before treating them as checker inputs. These omissions can affect semantics, so they are not classified as merely cosmetic syntax errors. Figure 4 leaves unrelated state unconstrained, uses logs’[i]=v in B versus singleton {v} in A/BΔ, and BΔ initialization quantifies k while referring to i. Appendix B’s quorum assumption prints Q⊆Quorum rather than Q⊆Acceptor (Raft variants print both). UpdateLog prints logBallot’[i] without the acceptor index. ProposeEntries prints IF i1=0 THEN raftlogs[a][i1−1][1] ELSE −1, reversing the expected initial-index test. Some modules omit introduced variables from vars/init and omit frames for new variables; PQL Apply, GrantLease and UpdateTimer preserve MP!vars but leave other PQL variables unconstrained. These are findings about the printed artifact, not executed counterexamples against the authors’ implementation or an independently obtained historical proof. For distributed-system verification, this contributes a concrete specification-transformation method and useful cases of implicit acknowledgments, state mappings and safe optimization transfer. It also separates invariant preservation from progress and measured speed, and highlights the need to check exact proof artifacts, initialization, frame conditions and batch simulation. It contains no Verus, verified-Rust or LLM proof-agent experiment. No author code, prover or model checker was run.
    • limits: already-correct input specifications; valid state and parameter mappings; added actions preserve old state with explicit frame conditions; compatible initialization; quorum intersection, crash faults and persistent state; real lease-clock implementation; invariant preservation does not imply general liveness; manually written implementation is not verified; reported TLAPS proof source not recovered; printed listing concerns are not executed counterexamples
    • how much was read: most of it read
    • source
    • record id: on-the-parallels-between-2019
  • SecCSL (2019)
    • title: SecCSL: Security Concurrent Separation Logic.
    • what: SecCSL extends concurrent separation logic with relational assertions for data-dependent value sensitivity and location sensitivity. Assertions can express pointers, arrays, shared invariants, and security labels; lock invariants combine functional heap facts with policies for attacker-observable sinks. The logic’s compositional noninterference property is timing-sensitive, so branches on secret values are forbidden. The authors mechanize soundness in Isabelle/HOL and implement SecC, a symbolic-execution verifier for a C subset. The central case study is a lock-protected record whose classified flag controls data sensitivity and whose public OUTPUT_REG sink must never receive secret data; a variant of Covern’s CDDC case study and known benchmark problems are reported as verified within milliseconds in the abstract/overview.
    • number: SecC targets a subset of C
    • number: well-known benchmark problems reported within a few milliseconds
    • number: one concurrent lock/record/OUTPUT_REG case study plus CDDC variant
    • number: soundness mechanized in Isabelle/HOL
    • limits: The logic targets shared-memory, lock-based synchronization and passive attackers; security includes timing of observable updates. Secret-dependent branching is prohibited to preserve compositionality, though the authors suggest future relaxation. The extracted paper contains the design/overview and reports but limited detailed benchmark tables. Verification assurance depends on SecCSL soundness and the modeled C subset; it does not cover arbitrary concurrency primitives or active attackers.
    • how much was read: most of it read
    • source
    • record id: seccsl-2019
  • SPECTRL (2019)
    • title: A Composable Specification Language for Reinforcement Learning Tasks
    • what: Introduces SPECTRL, a language with achieve, ensuring, sequencing (;), and disjunction (or) over state predicates. A compiler builds a task monitor (an automaton with registers), augments state and action spaces, and generates quantitative plus subtask-progress reward shaping. Any RL optimizer can then learn a policy for the compiled MDP; the projected policy carries monitor memory. The monitor resolves non-Markovian sequencing by recording completed subtasks and exposes nondeterministic transition choices as actions. Quantitative semantics use max/min over trajectory segments; shaped rewards preserve rollout ordering under explicit lower/upper bounds on final and progress rewards. Theorem 3.1 links Boolean satisfaction to existence of a positive-reward augmented run; Theorem 3.2 proves ordering properties of the shaped reward. SPECTRL is implemented with ARS and modular neural networks, and is tested on seven waypoint/obstacle/fuel tasks plus continuous-action CartPole.
    • number: Seven specifications φ1–φ7; SPECTRL success curves near 100% for φ1–φ5 and in 4/5 runs for φ6–φ7
    • number: Compared with TLTL, CCE and unshaped SPECTRL; CCE degrades when obstacle+fuel constraints are added, while TLTL/CCE fail on memory-heavy φ5–φ7
    • number: SPECTRL success rate at least 97% for each benchmark task (abstract)
    • number: CartPole: SPECTRL converges faster than TLTL; CCE cannot learn a satisfying policy
    • limits: Policy guarantees are probabilistic optimization objectives, not formal synthesis guarantees for stochastic dynamics. Reward shaping’s policy-order preservation assumes deterministic MDPs for the stated guarantee and requires known bounds C_l and C_u. The language has finite-horizon rollout semantics and user-supplied quantitative predicate functions whose sign must match Boolean truth. Experiments use a 2-D noisy point robot, horizon 40, hand-designed tasks and ARS; scalability beyond the tested nested sequencing depth and other RL algorithms is not established.
    • how much was read: most of it read
    • record id: spectrl-2019
  • TLA+ Toolbox (2019)
    • title: The TLA+ Toolbox
    • what: Describes the TLA+ Toolbox IDE workflows, integrating TLC model checking, TLAPS hierarchical proofs, PlusCal translation, CloudTLC distributed execution, a profiler for state-space explosion, and trace exploration. CloudTLC provisions cloud instances and imports results transparently; profiler records invocation/cost and action state statistics, exposing inefficient expressions. Results/history are versionable XML, and Trace Explorer handles traces with thousands of states. Toolbox is open source and designed for engineers rather than theorem-prover experts.
    • number: Previous Toolbox release downloaded approximately 20,000 times; standalone model checker about one-tenth
    • number: Trace Explorer handles traces with thousands of states
    • number: Example profiler: action b produced 87 states, 29 distinct; action d evaluated 153 times with zero states
    • limits: TLC checks finite models; TLAPS handles deductive proofs but finding invariants remains manual. Profiling adds non-negligible overhead and is unavailable in distributed mode. Cloud startup dominates short runs; TLA+ is specification-level and does not generate implementation code.
    • how much was read: most of it read
    • record id: tla-toolbox-2019
  • DPA/MCMT (2018)
    • title: Formal Specification and Verification of Dynamic Parametrized Architectures
    • what: Defines Dynamic Parametrized Architectures (DPAs), where indexed component sets, connections, initial configurations, invariants and reconfiguration transitions are first-order formulas over unbounded index sets. It translates information-flow reachability into array-based transition systems and checks the resulting safety problem with MCMT/Yices. The formal language separates parametrized architecture guards from dynamic formulas, restricts transition syntax so index sets and parameter arrays can be rewritten into array updates, and translates component presence plus taint propagation into an array-based safety system. The paper proves that the translation stays in the array-based fragment and that information-flow witnesses correspond exactly to unsafe traces. A C/GNU-Bison extended-AADL translator and five scalable benchmark families expose transition-count, quantifier and solver-call bottlenecks.
    • number: MCMT timeout 1000 seconds
    • number: Converging safe n=6: 29,907 SMT calls; transition limit at n=7
    • number: Converging unsafe transition limit at n=5
    • number: Sequence timeout n=6 safe and n=7 unsafe
    • limits: Index sets are finite subsets of a countable universe, while the state space is unbounded across configurations. Component and connection guards are quantifier-free; initial, invariant and transition formulas obey restrictive quantifier/update/frame syntaxes. Verification targets reachability-style information flow, not noninterference or liveness; the paper explicitly leaves noninterference open. MCMT imposes at most two universal variables in Init, two existential variables per transition, 50 transition disjuncts, four existential variables in unsafe formulas and ten index variables per term. General dynamic information flow is undecidable (Minsky 2-counter encoding), and experiments time out or hit these limits.
    • how much was read: most of it read
    • record id: dpa-mcmt-2018
  • Formal Verification of Usage Control Models: A Case Study of UseCON Using TLA+ (2018)
    • what: # Formal Verification of Usage Control Models: A Case Study of UseCON Using TLA+ (authored by agents unless marked 🧑) Antonios Gouglidis, Christos Grompanopoulos and Anastasia Mavridou, MeTRiD 2018, EPTCS 272, pp.52–64, DOI 10.4204/EPTCS.272.5. The paper specifies concurrent usage-control lifecycles and reports finite TLC checks for pre-authorisation and ongoing-authorisation models. The authors claim correctness for “≀ 12 uses”; Table 2 gives measurements at 2, 8 and 12. These are bounded model results, not a proof for arbitrary populations or an implementation. Printed temporal formulas also have substantial specification issues that cannot be reconciled with the reported checks without the executable models (Q0,Q7–Q10). ## Reading and evidence Read all 13 pages, sections 1–5 and all eleven references. Inspected four figures, two tables and all displayed definitions/actions/formulas. Viewed eight individual renders, pages 5–12, including enlarged printed safety/liveness formulas and Table 2. The inventory, official arXiv and official EPTCS PDFs are byte-identical. Formula symbols lost in extracted text were checked against the renders. No executable TLA+ module, TLC configuration or run log was acquired. Section 2 says “see TLA+ specification in [1]”, but reference [1] is Microsoft’s TLA+ Tools page, not an identified UseCON model archive (Q1,Q11). The saved PDF’s active links point to tools, cited publications and license information. This is a bounded artifact-location finding, not a claim that no source can exist elsewhere. No author code/model executed or imported, no TLC/compiler/checker/solver run and no serialized scientific results loaded. ## Model and concrete cases UseCON adds a use entity to subjects, objects and actions. A use records a request’s subject/action/object identifiers, lifecycle status and mutable use attributes. U, the set of use records, is the only declared state variable. Subject/object/action records and their identifiers are treated as constants; administrative changes to their attributes are outside the modeled operation. Initially U is empty. Policy-related history can be read through existing uses (Q1,Q2). Direct policies use attributes of the requesting subject, object and action. Indirect policies select a related entity using CHOOSE; the example checks whether a child’s father has premium membership. Complex indirect policies aggregate selected entities; the example sums a customer’s account balances. Correct interpretation of CHOOSE requires an appropriate selected entity; existence/uniqueness conditions are not developed as part of these examples. The paper illustrates expressiveness but leaves verification of complex and interacting ongoing policies as future work (Q3,Q10). Induced use attributes come from participating entities, such as a service price. Observed attributes require an external observation, such as the system time when access is activated. Update procedures change status and other use attributes together. SystemTime is illustrative rather than a concrete bounded clock model. Administrators must supply policy-specific procedures and finite domains for any TLC instance (Q2–Q4; reader finite-model qualification). The pre-authorisation lifecycle is initial→requested→activated→completed or requested→denied. Request and Complete are subject actions; preEvaluate is a system action. Next is their disjunction. Request nondeterministically chooses a subject/action/object tuple absent from existing records. Because terminal records remain in U and the uniqueness test uses only that tuple, the printed transition rules do not permit requesting the same tuple again in that model lifetime. This restricts the workload compared with repeated real-world accesses (Q5; reader inference). For ongoing authorisation, Request is followed by Activate without a prior policy test. onEvaluate keeps the use active and updates attributes if the policy holds, or changes it to stopped otherwise; Complete changes active to completed. Next includes all four actions. The evaluation interval is explicitly left to implementation. Thus the model does not establish a maximum revocation delay or that a policy is continuously true between evaluations (Q6). All update actions are assumed atomic. The authors justify this with a central policy decision point and the absence of updates to subject/object attributes. Concurrent operations are represented by interleaving these whole actions; message loss, replication, distributed transactions, crashes and partial updates are not modeled here. There is no implementation-refinement proof showing that a deployed access-control service realizes these atomic steps (Q4–Q6). ## Intended properties and printed formulas TypeCorrectness is U⊆Uses, where Uses is a finite-domain record type. Table 1 lists forbidden status changes and intended progress. Pre-authorisation forbids leaving completed or denied and returning from activated to requested/denied; it expects requested uses eventually to activate or be denied, and activated uses eventually to complete. Ongoing authorisation similarly forbids leaving completed/stopped or returning from activated to requested; it expects requested uses to activate and eventually complete or stop (Q7). The printed safety formula is □(∃u∈U: u.st=“completed” ⇒ □(u.st≠“requested”)), where □ means always. This is existential, although the prose says the condition applies to all uses. With the natural quantifier scope shown by the parentheses, the existential is false when U is empty; Init explicitly sets U={} so the formula fails in the initial state. Further, u denotes a bound record value. The inner u.st does not look up that use’s changing record in future U states. A completed bound record retains its completed field even if U later contains a replacement record with the same identifiers and a different status. These are semantic issues in the printed formula, not an executed TLC counterexample (Q4,Q7; reader interpretation). The liveness formula is ∀u∈U: u.st=“activated” ↝ u.st=“completed”, where ↝ means that whenever its left condition holds, the right condition eventually holds. U is quantified at the point where this formula is evaluated. As a top-level property evaluated initially, it is vacuously true because initial U is empty. If evaluated at a later state with an active record, that bound record value does not evolve into the completed record. Adding an outer □ alone would not repair this identity/update issue; the property needs stable identifiers and a state-dependent lookup (Q2,Q4,Q8; reader interpretation). The paper supplies Init and Next but no complete temporal specification or fairness assumptions. A disjunction of enabled actions alone does not require an enabled completion or policy evaluation eventually to be selected. In the ongoing model, an active use can remain active through onEvaluate repeatedly while completion is postponed. If stuttering is allowed by the full specification, it gives another way to postpone progress. Scheduling/fairness and policy assumptions must therefore be explicit for an eventual-completion theorem. No such theorem can be recovered from the displayed transitions alone (Q5–Q8; reader separating behavior). There are also printed notation inconsistencies: action guards and createUse use state while other definitions and updates use st; record definitions and extra braces in the ongoing actions are not a complete executable module. These discrepancies could differ from the authors’ actual checked models. They prevent treating the printed listings as independently validated source. The reported no-error checks and the initial-state safety failure cannot both refer literally to the same displayed property under standard quantifier interpretation; the missing modules/configurations leave the correspondence unresolved (Q2,Q5–Q9). ## Measurements and their scope The authors use TLA+ Tool 1.5.6 and TLC 2.12 on a mid-2014 MacBook Pro, OS X El Capitan, 2.5GHz Intel Core i7 and 16GB 1600MHz DDR3. Table 2 contains six configurations. Each tuple below gives uses; reported diameter; generated states; distinct states; deadlock-check seconds; safety/liveness seconds (Q9). - Pre: 2;6;21;12;1;3 - Pre: 8;23;277,969;16,832;2;5 - Pre: 12;31;45,533,665;560,128;53;138 - Ongoing: 2;7;33;16;1;3 - Ongoing: 8;25;367,873;23,808;2;7 - Ongoing: 12;37;79,112,449;1,224,704;118;241 All 36 numeric cells were transcribed from the rendered table. Diameter is retained as the paper’s reported label; no TLC statistics were independently regenerated. State-count growth and interrupted larger runs demonstrate an exploration limit for this setup. Table 2 does not document every integer population below 12, all policy choices or all attribute domains. The exact subject/object/action split, policy instances, bounds and fairness configuration are not supplied in enough detail to reproduce these counts (Q9). The paper calls the first experiment deadlock-freedom checking, then describes TLC stopping at a deadlock after every pre-authorisation use is denied or completed. Its conclusion says “The trace of the deadlock errors verifies that the defined specifications of the system operate correctly.” A permitted terminal state and an unexpected stuck state need separate acceptance conditions. These traces can support an intended-termination inspection, but their existence does not itself establish deadlock freedom, exhaustive termination of every behavior or the temporal formulas above (Q9,Q10). The authors report no safety/liveness errors for the bounded configurations. No model files, logs, certificates or reproduced checks establish which executable formulas produced that result. The appropriate record is therefore an author-reported bounded check, accompanied by the printed-formula issues. Larger populations were stopped for time; no cutoff theorem extends the small checks to arbitrary numbers of uses (Q9,Q10). ## Contribution to the topic This is a concrete TLA+/TLC case study of security-related lifecycle modeling, finite-state exploration cost and intended safety/progress distinctions. Its central-state atomic model is relevant to concurrent systems but does not verify a distributed protocol or a Rust/Verus implementation. No LLM specification/proof agent is evaluated. Complex interacting policy verification, composition with secBIP and arbitrary-population guarantees are future work (Q10). For evaluating generated specifications, the paper provides useful failure modes: temporal quantification over an initially empty set, confusing a fixed record with a changing entity, omitted fairness, treating a terminal deadlock as a general correctness argument, and incomplete correspondence between printed formulas and reported checker success. These are reader lessons from this paper, not author-demonstrated LLM failures.
    • limits: boundedatomiccentralmodel;constantentityrecords;policydomains/fairnessmissing;printedformulasnotverifiedexecutablemodels
    • how much was read: most of it read
    • source
    • record id: formal-verification-of-usage-2018
  • Layered Concurrent Programs (2018)
    • what: Formalizes layered concurrent programs, a single imperative concurrent notation containing a sequence of concrete-to-abstract programs with common code written once. A type system extracts each layer and checker programs; refinement is reduced to cooperative safety of checkers plus safety of the top abstraction. Defines gated atomic actions, parallel calls, preemptive and cooperative semantics, and mover-type commutativity. The projection and reduction theorems show that cooperative checker executions cover preemptive behaviors; instrumentation tracks snapshots and exactly one abstract action across preemption-free fragments. The lock example refines CAS/RESET spinlock to an ownership-aware abstract lock and then skip; Civl uses Boogie and has verified a garbage collector and race detector, with about fifty smaller examples including ticket lock and lock-free stack.
    • number: three-layer spinlock example
    • number: h checker programs for h refinement steps
    • number: around fifty smaller Civl programs
    • number: Section 6: around fifty smaller programs; large cases are a concurrent garbage collector and a data-race detector
    • limits: Soundness requires pairwise commutativity and mover annotations, disjoint outputs/linearity conditions, safe checker programs under cooperative semantics, and a safe top abstract program. The result is safety/refinement only, not liveness. The paper reports no new quantitative benchmark table; executable code generation, scalability, and IDE integration remain open, and concrete atomic-action gates remain trusted specification points.
    • how much was read: most of it read
    • source; notes: Civl and inductive sequentialization
    • record id: layered-concurrent-programs-2018
  • Modular Paxos verification (2018)
    • title: Paxos Consensus, Deconstructed and Abstracted (Extended Version)
    • what: # Paxos Consensus, Deconstructed and Abstracted: whole paper reading (authored by agents unless marked 🧑) Álvaro GarcĂ­a-PĂ©rez, Alexey Gotsman, Yuri Meshman and Ilya Sergey’s extended Paxos Consensus, Deconstructed and Abstracted is arXiv:1802.05969v1,16 February 2018. All 44 pages were read: eight sections, Appendices A–E, all 17 figures, four theorems, five lemmata, four definitions, examples 1–6, all printed proof outlines and 32 references. All 11 contact sheets and individual15,18,21,22,28,32,33,44 were inspected. The original, local and official PDFs match. No author code, scientific-result artifact or formal checking tool was executed or loaded. [Evidence: Q0, frontmatter/v1 identity, PDF pp.1–1; literal spans in quotes.json.] The paper separates two verification problems: proving single-decree Paxos through composable shared-memory object specifications, and deriving Multi-Paxos by transformations of message handling. It adapts Boichat et al.‘s Paxos→Round-BasedConsensus→Round-BasedRegister decomposition. The lower specifications deliberately admit unsuccessful operations that nevertheless expose values to other operations. The aim is to preserve each unchanged module’s proof when changing another module or the network implementation. Claims of being the first such modular verification belong to these authors; this reading does not establish historical priority. [Evidence: Q1, §1, two contributions, PDF pp.2–3; Q28, §7, complete comparisons/claimed novelty, PDF pp.24–25; literal spans in quotes.json.] The setting is crash-stop, majority-quorum consensus, not Byzantine consensus or crash-recovery with durable storage. The basic network neither invents, changes, drops nor duplicates messages, delivers with unbounded delay, and has nonblocking send/blocking receive. Later transformations explicitly introduce selected read-request duplication. Leader election is omitted under an assumption that one correct process trusted by all other correct processes always exists. No failure-detector implementation, storage-recovery proof or general termination proof is supplied. Finite trace refinement and linearizability establish safety properties, not eventual completion: lower specifications may repeatedly choose failure. [Evidence: Q2, §3, decomposition/leader assumption, PDF pp.4–5; Q3, §3, network/imperative language, PDF pp.5–5; Q4, §1, safety scope, PDF pp.1–1; Q19, Definition1, full configuration traces, PDF pp.18–18; literal spans in quotes.json.] Acceptors retain promised round r, accepted round w and value v. A read(k) gathers distinct-sender acknowledgments from ceil((n+1)/2) acceptors and chooses the value with highest accepted round, or undef. A write(k, v) gathers an equal majority; either operation can fail after a nack. Acceptors accept requests at k≄r and atomically update state with their acknowledgment send. A proposer uses rounds pid, pid+n, pid+2n,
; this guarantees disjoint rounds between processes under one continuing invocation per process. Reinvoking the printed entry operation resets k to pid, so repeated independent calls need fresh-instance state or persistent counters. Fixed process identities and trustworthy message origins under the assumed transport model, plus matching request rounds, are essential. [Evidence: Q6, Figure3/§3, complete read/write implementation, PDF pp.6–6; Q7, Figures4–5, acceptor and entry implementation, PDF pp.7–7; Q8, §3, entry and unique rounds, PDF pp.8–8; Q3, §3, network/imperative language, PDF pp.5–5; literal spans in quotes.json.] The top sequential specification stores one value, choosing the first proposal and returning that value thereafter. Its concurrent implementation can decide another process’s previously exposed proposal; ghost pending-thread entries let one invocation linearize that proposing operation first and then itself. This is helping: a thread’s logical effect may occur during another thread’s step. The proof assumes unique proposal values, one pending slot per process and single-assignment result cells. A concrete invocation identity or a justification that unique tagging preserves client-visible equality would be needed to generalize beyond that stated setting. Abstract results are declared Boolean in Figure 7 although proposal values have type val; this is a printed typing mismatch. [Evidence: Q5, Figure2, atomic entry specification, PDF pp.4–4; Q10, §4/Figure 7/Theorem 1, complete top refinement, PDF pp.9–10; Q30, Appendix A, complete top-level proof outline, PDF pp.27–29; literal spans in quotes.json.] Figure 6 gives the reason for weakening the intermediate abstractions. A low-round write can fail overall yet reach one acceptor, after a higher-round quorum has already decided another value. An overlapping read may see that isolated value and complete successfully, although its subsequent write will fail. Real-time order and this information flow can require the failed write to linearize before the read. The abstract specifications therefore retain sets of exposed values rather than only the globally decided value, allow reads at stale rounds and allow a write at an otherwise eligible round to fail because a concurrent operation overtakes it. [Evidence: Q9, §3/Figure 6, complete histories and rationale, PDF pp.8–9; Q11, §4/Figure8, round consensus contract, PDF pp.10–12; Q12, Figure9/§4, complete register contract, PDF pp.12–12; literal spans in quotes.json.] Round-BasedConsensus’s atomic proposeRC(k, v0) nondeterministically selects vD and a success flag. If vD is already exposed or equals v0, it adds vD to valsRC even on failure; success additionally needs k≄roundRC and retains the first decided vRC. Round-BasedRegister is weaker: every write exposes its input, a successful eligible write updates roundRR and vRR, and a read may return any exposed value when its round is stale. Its vRR is not itself an immutable consensus decision. The enclosing read-before-write discipline and unique increasing rounds are needed to recover the deterministic top specification. Theorem 2 places logical effects at failed read or completed write. [Evidence: Q11, §4/Figure8, round consensus contract, PDF pp.10–12; Q12, Figure9/§4, complete register contract, PDF pp.12–12; Q13, Theorem 2, round consensus linearization, PDF pp.12–12; literal spans in quotes.json.] The register proof uses prophecy variables: ghost values selected according to how an operation eventually returns. Successful reads are intended to linearize when the quorum-th read acknowledgment is sent, successful writes at the quorum-th write acknowledgment, failed reads at their nack return, and failed writes at the first accepting response or at the failure return if none accepted. These are proof annotations, not an implementable ability to predict network schedules. Ghost counters count acknowledgments sent, whereas concrete quorums count acknowledgments received. The basic no-duplication premise is used in relating those quantities. [Evidence: Q14, §4, register prophecy/linearization explanation, PDF pp.12–14; Q15, Figure10, complete instrumented read/write, PDF pp.14–14; Q16, Figure 11/Theorem3, complete annotated acceptor, PDF pp.14–15; Q32, Appendix C, complete register proof outline/invariants, PDF pp.31–41; literal spans in quotes.json.] Reader source-level objection to the printed read annotation: Figure 11 requires both count_r[k]=quorum−1 and proph_r[k]=(true, v), where v is that particular acceptor’s local value. The eventual read result is instead the maximum accepted-round value among received acknowledgments. With n=3, let A1 hold (vA, w=1) from a failed write and A2 hold undef. A read at k=3 returns vA after receiving A1’s then A2’s replies. When A1 sends, count=0 rather than 1; when A2 sends, count=1 but its undef differs from the prophecy vA. A third sender sees count=2. No successful-read annotation fires. This ordinary schedule substitution identifies a proof-instrumentation gap, not a conflicting-decision attack or an executed trace. The proof needs an annotation tied to the relevant quorum maximum, not equality with an arbitrary quorum-th sender’s value. [Evidence: Q15, Figure10, complete instrumented read/write, PDF pp.14–14; Q16, Figure 11/Theorem3, complete annotated acceptor, PDF pp.14–15; Q32, Appendix C, complete register proof outline/invariants, PDF pp.31–41; Q9, §3/Figure 6, complete histories and rationale, PDF pp.8–9; literal spans in quotes.json.] The incomplete-operation case also needs care. The paper leaves a never-returning write’s prophecy undef and never linearizes it, although it may already change an acceptor and supply a value read by another operation. A standard linearizability proof can complete selected pending operations; this annotation needs to support those completions rather than erase every nonreturning writer. Separately, after correcting the acknowledgment predicate notation, Appendix C’s intended Val(j, v) invariant equates the current value with existence of a historical write acknowledgment for v. After accepting v1 then v2, the retained message history still contains the acknowledgment for v1 but the current value is v2, contradicting the reverse implication. The intended invariant needs a latest-round qualification. These are reader proof obligations, not a rejection of Paxos’s ordinary quorum argument. [Evidence: Q14, §4, register prophecy/linearization explanation, PDF pp.12–14; Q16, Figure 11/Theorem3, complete annotated acceptor, PDF pp.14–15; Q32, Appendix C, complete register proof outline/invariants, PDF pp.31–41; literal spans in quotes.json.] The appendices contain additional transcription problems material to mechanization. Appendix A’s loop annotations use pid=k mod n despite initializing k=pid and maintaining the owner formula ((k−1) mod n)+1; n=3, pid=3, k=3 gives3≠0. They also assert a false pending flag after an unsuccessful iteration, although that branch does not clear it. Appendix B’s rely relation prints an index condition (k mod n)≠(k mod n), with no distinct index, which would exclude all interference literally. Appendix C’s req/ack predicates reuse the same message identity for a request and its reverse-direction acknowledgment; for different endpoints those fields cannot both hold. These details must be corrected before treating the outlines as machine-checked proofs. [Evidence: Q30, Appendix A, complete top-level proof outline, PDF pp.27–29; Q31, Appendix B, complete round consensus proof outline, PDF pp.29–31; Q32, Appendix C, complete register proof outline/invariants, PDF pp.31–41; literal spans in quotes.json.] The network layer models local states, protocol transition relations and a multiset of uniquely identified messages retained after reception with active=false. A simple execution chooses an internal step, send or receive at one node. Appendix D flattens proposer code, carries the residual program text in each local state and gives send/receive rules; it leaves ordinary WHILE-language semantics assumed. Thus program counters and auxiliary loop variables are part of this encoding, not invisible implementation details. Receive rules in Figures13–14 also print an unbound n where the destination-node update is intended. [Evidence: Q17, §5.1, local states/messages/transition relations, PDF pp.16–17; Q18, Figure13/§5.1, network steps, PDF pp.17–18; Q33, Appendix D, complete code-aware encoding, PDF pp.41–44; literal spans in quotes.json.] Out-of-thin-air semantics adds selected read requests without changing local state, justified by predicate P when the proposer has reached at least that round. Lemma 1 claims its complete configuration traces are included in the simple semantics. Appendix E’s entire argument says a read request does not change proposer state and has no nontrivial precondition. That does not directly match Appendix D’s code-aware encoding, where executing send advances the residual program and loop, and a particular round/destination request is sent once. Extra duplicate requests with unchanged program state therefore need an explicit observation/projection or a different reusable-send protocol. The source’s exact-trace inclusion is stronger than client-visible equivalence and its printed one-sentence proof does not bridge them. [Evidence: Q20, §5.2, complete OTA rule/predicate/Lemma 1, PDF pp.18–18; Q19, Definition1, full configuration traces, PDF pp.18–18; Q33, Appendix D, complete code-aware encoding, PDF pp.41–44; Q34, Appendix E, complete transformation/composition proofs, PDF pp.44–44; literal spans in quotes.json.] Slot replication runs an independent single-decree instance per slot; projection to any slot recovers its base behavior up to stuttering. Widening then copies a triggering read request to all slots at the same recipient. Its refinement requires OTA compliance and P-monotonicity: a request justified at one sender slot must be justified at every other sender slot. Example 4 correctly excludes independently advancing rounds and supplies fixed-round instances as a positive case. Example 5 immediately invokes the unrestricted Section 3 implementation, whose rounds retry independently; the required synchronization/restriction is not established there. An independent-slot source-level case uses n=3, pid=1, with sender slots at rounds 4 and 1: request k=4 satisfies P in the first slot but not the second. The refinement must state a shared-round discipline rather than infer it from ordinary slot independence. [Evidence: Q21, §5.3/Figure14/Definition2/Lemma2, independent slots, PDF pp.18–20; Q22, §5.4/Definition 3, widening rule/OTA compliance, PDF pp.20–21; Q23, §5.4, Definition4/Examples4–5/Lemma3, PDF pp.21–21; literal spans in quotes.json.] Two further printed conditions need explicit scope. Definition 3 introduces a triggering subset T but then quantifies all messages m∈M instead of m∈M∩T; its read-only P would reject ordinary write/ack messages. Optimized widening’s receiveAndAct applies a received message to every slot without an explicit m∈T branch, despite T appearing in the rule’s name. Applying a slot-specific write everywhere would not preserve independent slots. Restrict the optimized rule to triggering read requests and retain ordinary per-slot reception for other messages. These are literal-rule qualifications, not evidence about the linked Scala implementation. [Evidence: Q22, §5.4/Definition 3, widening rule/OTA compliance, PDF pp.20–21; Q24, §5.5, all-slot optimized rule/Lemma 4, PDF pp.21–22; Q23, §5.4, Definition4/Examples4–5/Lemma3, PDF pp.21–21; literal spans in quotes.json.] Reader refinement qualification also applies to Lemmata 3–4. Widening consumes one active request and inserts replicas in the same transition; separate slot-replicating receive and OTA send transitions introduce intermediate configurations. Appendix E explicitly says, “This allows us to emulate this step by a per-slot execution of the OTASend.” That establishes a multistep simulation argument, while Lemma 3 states inclusion of complete configuration traces. Lemma 4 permits compression of intermediate configurations, but expanding receives also leaves inactive replica requests in message history; the optimized rule does not insert that same history. A specified observation/refinement mapping must account for grouped steps and internal request histories, not just remove intermediate configurations. These are source-level proof obligations, not executed counterexamples or consensus-safety violations. [Evidence: FR_FQ19, §5.1, observation definition, PDF pp.17–17; FR_FQ25, §5.4, WStepReceiveT adds replicas while consuming the original, PDF pp.20–20; FR_FQ26, §5.5, optimized widening has no triggering-set guard, PDF pp.21–21; FR_FQ27, §5.5, Lemma 4 configuration compression, PDF pp.22–22; FR_FQ40, Appendix E, Lemma 3 simulation uses multiple steps, PDF pp.44–44; literal spans in quotes.json.] Optimized widening batches one recipient’s per-slot receive, local and reply steps; Lemma 4 relates it to expanding those local sequences. Bunching packages the resulting replies in a message, caches/unpacks them on demand and maps them back to separate messages in Lemma 5. The intended benefit is amortized Phase 1 across slots while reusing single-decree proofs. Because the model permits infinitely many slots, its all-slot batch needs a finite or lazy representation before implementation. The register-provider interface exposes independent write-once slots; it does not itself prove client request deduplication, gap-free log execution, application linearizability or leader-lease correctness. [Evidence: Q24, §5.5, all-slot optimized rule/Lemma 4, PDF pp.21–22; Q25, §5.6/Figure15/Lemma 5, bunching/unpacking, PDF pp.22–23; Q26, §5.7–6, composition/interface/stability, PDF pp.23–24; Q27, §6, Scala/Akka prototype/Theorem 4, PDF pp.24–24; literal spans in quotes.json.] Theorem 4 composes Theorem 1 with the transformation lemmata to claim refinement of an array of atomic write-once registers. Appendix E supplies short proofs of Lemmata 1–3 and Theorem 4; Lemmata 4–5 have statements/explanations in the body but no separate extended proofs. Stable rely/guarantee assertions are the stated condition for transporting program reasoning across network transformations. The paper’s conclusion proposes Raft, PBFT, Mencius, master leases and epoch numbering as future applications, without establishing those results here. [Evidence: Q26, §5.7–6, composition/interface/stability, PDF pp.23–24; Q34, Appendix E, complete transformation/composition proofs, PDF pp.44–44; Q29, §8, contributions/proposed extensions, PDF pp.25–26; literal spans in quotes.json.] Validation is a Scala/Akka proof-of-concept linked at github.com/certichain/protocol-combinators, plus handwritten specifications, annotations and proof outlines. The paper reports no benchmark configurations, performance measurements, experiment counts or machine-checked artifact for its own argument. “Executable” and “provably correct” are the authors’ descriptions; source-code refinement and runtime-library correctness were not inspected in this reading. TLA+, PVS, Isabelle, EventML, PSync, Ivy, IronFleet, Verdi and Disel appear as related work, not tools used to check these particular proofs. [Evidence: Q27, §6, Scala/Akka prototype/Theorem 4, PDF pp.24–24; Q28, §7, complete comparisons/claimed novelty, PDF pp.24–25; Q34, Appendix E, complete transformation/composition proofs, PDF pp.44–44; literal spans in quotes.json.] For this database the main contribution is proof reuse across both object abstraction and protocol-aware network optimization, with failed-write information flow as a concrete test of specification adequacy. Reader follow-ups are a TLA+ model of ghost-free concrete histories and slot/round synchronization; Verus/Rust ownership and typed sender/instance proofs for a finite lazy network adapter; and LLM proof-agent tasks checking prophecy coverage, pending-operation completions, stable interference assertions and exact refinement observations. No Verus, verified Rust or LLM evaluation is reported. These proposed checks should distinguish repairing printed proof outlines from discovering an actual consensus safety violation. [Evidence: Q1, §1, two contributions, PDF pp.2–3; Q14, §4, register prophecy/linearization explanation, PDF pp.12–14; Q23, §5.4, Definition4/Examples4–5/Lemma3, PDF pp.21–21; Q27, §6, Scala/Akka prototype/Theorem 4, PDF pp.24–24; Q29, §8, contributions/proposed extensions, PDF pp.25–26; literal spans in quotes.json.]
    • number: Module proofs can be reused across implementations
    • number: Crash-failure Paxos setting
    • limits: Crash-stop failures; majority quorums; reliable transport with no invented, modified, lost or duplicated base messages; fixed process identifiers; unique proposals and disjoint increasing rounds under one continuing invocation per process; correct trusted leader assumed. Handwritten proof annotations require repairs. Transformations need stable assertions, cross-slot P-monotonicity, triggering-message guards, and an observation/refinement mapping.
    • how much was read: most of it read
    • source
    • record id: modular-paxos-verification-2018
  • Nickel: A Framework for Design and Verification of Information Flow Control Systems (2018)
    • what: Nickel verifies that deterministic sequential system interfaces and their C implementations satisfy information-flow policies. A state-dependent action-domain function and possibly intransitive flow relation define permitted influence. Noninterference compares observations after original and optionally purged action histories. Coq-proved unwinding and restricted-refinement theorems reduce system proofs to Z3 checks over individual operations. Demonstrations cover the NiStar DIFC kernel, NiKOS process isolation and a repaired ARINC 653 interface specification. Records exact purge and seven unwinding obligations, lockstep data/policy refinement, trusted policy/checker/initialization boundaries, deterministic/uniprocessor/static-policy restrictions, manual observational equivalence, all object/label/quota/scheduler mechanisms, concrete covert channels and interface redesigns, complete LOC cells, verification/effort times and the logical-time experiment. Separates mechanized metatheory from trusted SMT implementation and ARINC specification analysis from kernel implementation verification.
    • limits: §§1,3.1,3.5,6.3: Only sequential deterministic state machines, with system-call/trap handlers atomic on a uniprocessor. NiStar disables timer interrupts in kernel space and all other interrupts, using polling drivers. This does not establish security under multicore/shared-memory concurrency, weak memory or interleaved kernel handlers. §3.1 Definition1: Policy P=(D,flow,dom); domains represent exercised authority, flow is a fixed relation on domain pairs, and dom(action,state) may depend on the current thread/labels. Intransitive flow can allow p1→scheduler→p2 while forbidding direct p1→p2. A state-dependent dom does not make the can-flow-to relation dynamic; changing that relation is unsupported. §3.2 Definition2/Figures4–5: sources recursively tracks permitted direct or intermediate influence along a trace. purge is a SET of subtraces: it always permits retaining an action and permits dropping it only when its domain is outside sources, recomputing later state on the removed branch. Noninterference quantifies over every action, original trace and permitted purged trace and requires equal next-action output from the two resulting states. This is a relational security property over histories, not only memory isolation or functional refinement. §3.2: Authors establish reduction to classical noninterference for state-independent dom and monotonicity when flow is relaxed while domains/dom stay fixed. The PDF states these sanity checks but does not print their detailed proofs. Do not generalize monotonicity to changes of all policy components. §3.3 Theorem1/Figure6: Developers supply an inductive state invariant and per-domain observational equivalence. Seven universally quantified obligations cover invariant initialization/preservation, equivalence, consistency with dom, consistency with flow, output consistency, local respect and weak step consistency. Accepted invariants/equivalences are checked proof inputs, not trusted axioms; inventing an unsuitable relation can fail the checks. They remain substantial human work. §3.4 Theorem2: General refinement may introduce leaks. Supported data refinement requires same actions/outputs, related initial states, one-step preservation and equal output for related states satisfying the implementation invariant. Policy refinement additionally preserves dom for the same action/history and uses the same domain set/flow relation. No arbitrary stuttering, action splitting or nondeterministic refinement is claimed. §§3.5,6.2: Guarantees cover modeled interface observations, including logical scheduling time. Physical timing, sound, energy and microarchitectural channels outside the model are excluded. No distributed network fault, crash-recovery, availability, termination or fairness guarantee is supplied. The scheduler description assumes an infinite stream of timer interrupts rather than proving hardware progress. §4: Coq mechanizes the two general theorems. Python specifications/proof inputs and symbolic execution of C-derived LLVM IR produce Z3 obligations. Paper explicitly trusts information-flow policy, unwinding checker and Z3; implementation verification adds refinement checker and unverified initialization/glue. This is not an independently checked proof certificate for each SMT result or fully verified checker/compiler/hardware chain. §4: The intended policy is the trusted top-level requirement and needs auditing. Automated verification cannot show that an overly permissive policy matches the user’s security intention. A failed condition may reflect a genuine interface/implementation channel or insufficient invariant/observational equivalence; every solver counterexample is not automatically an exploit. §5: Determinism is obtained by exposing allocation choices as arguments, specifying allocation behavior precisely (NiStar), or hiding choices below the interface (NiKOS virtual addresses). Encrypted sequential names technically violate exact noninterference despite a claimed negligible practical leak; Nickel avoids them rather than proving probabilistic security. §§6.1–6.2: DIFC safe-flow relation combines sender and receiver ownership for controlled declassification/endorsement. Alice’s tty daemon is trusted to release secrets only to her terminal; a label proof does not verify that daemon’s declassification logic. Only threads/gates may have nonempty ownership. Fixed-size pages and finite interfaces aid SMT automation. §6.3: NiStar uses a kernel identity mapping and separate user/kernel page tables. The incomplete POSIX emulation, musl, lwIP, file-system wrapper and applications demonstrate usability; their existence does not extend the kernel proof to full application correctness, network security or durable filesystem semantics. §7: NiKOS mirrors a particular mCertiKOS interface after changing executable loading to make quotas agree. It is not a proof of every mCertiKOS variant. ARINC 653 result verifies a Python-modeled 14-operation communication interface after fixing three previously known channels; no ARINC kernel implementation/refinement proof or new bug discovery is reported. §8: Counterexamples for injected §2 examples and the round-robin workload demonstrate detection within these models. The logical-time plot supports its stated scenario, not absence of unmodeled physical channels. No Linux performance comparison, end-to-end application throughput benchmark, repeated-run confidence interval, or quantitative covert-channel capacity study is provided. §8 Figure11: LOC for interface implementation excludes shared C/x86 infrastructure; user-space LOC excludes third-party musl/lwIP. Effort figures are authors’ experience, not a controlled productivity comparison: one author six/two/one weeks for specification+verification, several researchers about six months implementing NiStar, and two months exploring framework definitions. §§9–10: Related work includes seL4/CertiKOS/Ironclad/Komodo and Covern, plus DIFC policy-synthesis tools; those citations do not mean Nickel supports concurrency or automatically synthesizes the complete policy/observational equivalence. No direct Verus, Rust, TLA+ or LLM-agent experiment. Public source pointer saved; artifact/proofs not run.
    • how much was read: most of it read
    • source
    • record id: nickel-a-framework-for-2018
  • TCS (2018)
    • title: Multi-Shot Distributed Transaction Commit
    • what: Defines Transaction Certification Service (TCS), a repeated transaction commit interface whose committed transactions must have a legal real-time-respecting sequential order for a configurable conflict-check function. States correctness of multi-shot 2PC under algebraic conditions on shard-local conflict checks, then a simulation from a crash-tolerant protocol that weaves certification into Paxos-style replication. Provides key invariants and an agreement proof; main theorem proofs are external. Gives analytic failure-free latency reductions from seven to four message delays, or three with all-to-all acknowledgements. The correctness definition linearizes the committed projection, so it imposes safety on commits without forcing every abort to be justified by the global conflict function. It separates checks against decided-commit transactions (f_s) from stronger checks against prepared-commit transactions (g_s); conditions (6)–(8) require global/local consistency, strengthening, and a cross-order commutativity property. Abstract 2PC deliberately allows forgetting and recalling final decisions: votes/order survive recovery while a leader can temporarily lose knowledge of an abort, affecting later certifications. The concrete protocol persists transaction-vote pairs at quorums, computes votes only at leaders, synchronizes recovered follower state, and allows multiple unreplicated coordinators. Invariant 7 proves one accepted vote and slot per transaction, using preservation across ballots and transaction uniqueness.
    • number: {‘shard_replicas’: ‘2f+1; quorum f+1; at most f crash-stop faults’, ‘failure_free_message_delays’: {‘vanilla_2PC_over_Paxos’: 7, ‘integrated_protocol’: 4, ‘all_to_all_variant’: 3}, ‘timing_scope’: ‘includes communication with client, analytical message delays, not measured wall-clock latency’}
    • number: TCS supports serializability and snapshot-isolation certification functions
    • number: Failure-free optimized protocol can expose a transaction decision in four message delays including the client, or three with all-to-all communication
    • number: Correctness is established through refinement theorems and invariants
    • limits: Optimistic concurrency control; each submitted transaction has completed its speculative execution and carries read/write/version information. Example writes are also reads, commit versions exceed read versions, and serializability additionally assumes read versions already exist in committed history. Global and local certification functions distribute over union via conjunction; f_s/g_s must satisfy (6)–(8). Serializability and snapshot-isolation instances are supplied, with different prepared-transaction checks. Asynchronous reliable FIFO channels; crash-stop faults. Each shard has 2f+1 processes with at most f crashes; shard groups disjoint for simplicity. FIFO is used to preserve prefix order at followers. Only safety established. Liveness is left to eventual consistent leader election or sufficiently long synchrony; retransmission details omitted. Theorem 1 proof is reference [7] Appendix A; Theorem 2 simulation proof is [7] Appendix B. Supplied 18 pages include no appendices, mechanization or executable implementation evaluation. Pessimistic/mixed concurrency control and Byzantine adaptation are proposed future work, not results.
    • how much was read: most of it read
    • source
    • record id: tcs-2018
  • Auxiliary Variables in TLA+ (2017)
    • what: # Auxiliary Variables in TLA+ (authored by agents unless marked 🧑) Leslie Lamport and Stephan Merz, arXiv:1703.05121v2, paper dated 27 May 2017. This is a practical account of extending TLA+ specifications with history, prophecy and stuttering variables so that state expressions can connect different representations of a concurrent system. Its central requirement is equivalence after hiding the added variables, not just that an augmented specification has some behaviors of the original. The worked snapshot result concerns safety of a simplified algorithm whose reads may never terminate. General language-independent soundness and completeness proofs are explicitly deferred to future work (Q1,Q2,Q16,Q21). ## Reading and evidence scope Read the complete 71-page PDF: cover, abstract, contents, printed pages 1–69, all sections 1–6.6, two numbered theorems, displayed definitions/equations, all 27 figure listings and all nine bibliography entries. The introduction says 25 figures, but numbering continues through Figure 27. There are no numbered tables, appendix or checklist. References were read as bibliography entries, not recursively followed. All 71 page images were generated; only PDF pages 19,20,27,39,40,41,44,45,46,48,49,54,57,62,66,67,68,70 were individually inspected. Complete extracted text was read for every page; this does not claim visual inspection of every page. Read the complete official project webpage, downloaded its 317-member ZIP, and read nine selected plaintext assets whole: Prophecy.tla, Stuttering.tla, AfekSimplified.tla, AfekSimplifiedH.tla, NewLinearSnapshotPS.tla, and both MC.cfg/MC.tla pairs under AfekSimplifiedH Model_1/Model_2. Other ZIP modules, prettyprints, model copies and result/log files were inventoried but not read. The retained files are exact archive bytes; each has a SHA256 and explicit scope. No author code, TLA+ module, TLC model, TLAPS proof or checker was executed/imported; no model/checkpoint or serialized experiment data was loaded. Static symbolic traces below are reader reasoning, not rerun results. The official webpage calls these “small TLC models”; their existence does not establish universal verification (W1,C1–C9). ## What an auxiliary variable must preserve A TLA+ specification describes behaviors, sequences of states allowing steps that leave the observed variables unchanged. Hiding a variable uses a temporal existential quantifier: it chooses an entire value sequence and includes the logic’s treatment of stuttering. It is not ordinary quantification over one state value. The paper first gives an approximate behavior intuition, then explains why stuttering makes that intuition incomplete. Definitions must be expanded with bound-name renaming; its NotUnique substitution example demonstrates how naive textual replacement can turn a valid expression into a contradiction. Recursive definitions are treated as fixed-point abbreviations, not arbitrary source-text rewriting (Q3,Q4). A refinement mapping substitutes state expressions for abstract variables; the implementation must imply that substituted specification. Forgetting auxiliary variable a must recover the original specification: ∃a:Spec_a is equivalent to Spec. Merely proving the projection implies Spec would permit the extension to remove original behaviors, even all of them. The examples teach how to avoid this loss, rather than offering an unbounded mechanized proof for every stated transformation (Q2,Q3,Q5). ## History: remembering information the implementation discarded MinMax1 stores all integer inputs in a set; MinMax2 stores only extrema. Both classify each input as Hi, Lo, Both or None. The set maps readily to its minimum and maximum, but an extrema-only state cannot reconstruct all forgotten intermediate inputs. MinMax2H adds h, initially empty, recording the inputs on response steps, which supplies the missing refinement state. Infinity and MinusInfinity are distinguished noninteger values; assumptions on these sentinels matter to empty-history handling (Q5,Q6). Theorem 1 gives a syntactic history-variable rule: augment Init with h=exp_Init; choose a disjunctive representation of Next; replace each subaction A by A conjoined with h’=exp_A; include h in the variable tuple. Expressions must obey the stated variable/context restrictions after definition expansion. Earlier discussion permits using the old history value in updates. The point of a disjunctive representation is to expose each enabled choice and its bound identifiers without changing conjunction/disjunction scope (Q6,Q7). Theorem 2 permits replacing a subaction A by B when they are equivalent under an invariant and for every identifier in the subaction’s context. Equation 3.2 is an action formula, which the paper says TLAPS can prove but TLC cannot directly check; TLC can instead compare the full temporal specifications on chosen finite models. A reported successful small comparison is not a proof for arbitrary state domains. Adding history to a specification with liveness retains the original liveness conjunct. Fairness can be expressed through the augmented actions when the required correspondence and enablement hold (Q7,Q8). ## Prophecy: exposing a later choice earlier in a proof SendInt examples choose a sent integer at different stages. A history variable cannot manufacture a choice still in the future. A prophecy variable p predicts it, constrains the action consuming that prediction, and can then choose a fresh prediction. Validity requires that each reachable original action has an admissible good prediction, rather than demanding a prediction for every syntactically describable state pair. Predictions that are not consumed must keep their intended relationship across steps (Q9). SendSetUndo lets an implementation remove pending elements; its prophecy array predicts send versus undo, and the mapping retains only predicted sends. SendSeqUndo adds ordering and shifting indices. A partial injection maps surviving old prediction identities to new identities. Injectivity prevents identifying distinct predictions and accidentally excluding behaviors. The prose in §4.5 calls DomInj a “partial function”, but both the formal condition and retained Prophecy module require membership in PartialInjections. The formal requirement is the one used here (Q10,Q11,C1). The three conditions combined in ProphCondition are: an available good prediction, a partial injection with the correct old/new domains, and PredDom containing every index whose prediction can affect the action predicate. PredDom may overapproximate those dependencies; consuming extra predictions safely allows extra refreshes. NewPSet preserves predictions only along unconsumed mapped identities and leaves consumed/new ones free. These obligations are properties of reachable actions of the original specification. The paper explains why a TLC checking module may need to end before declaring p: the original Spec does not constrain that variable. It recommends checking these conditions before the final refinement, which gives useful intermediate debugging obligations (Q11,C1). Liveness is retained from the original specification, not blindly replaced with fairness of the newly constrained NextP. In §4.6, allowing the prophecy value infinity would permit an endless stall in the safety formula; original weak fairness excludes that prophecy choice. Thus the combined formula can fail to be machine closed: its liveness condition rules out an otherwise allowed finite prefix, rather than only requiring later progress. The authors permit this as an intermediate proof instrument and caution against using it to describe an implementation. This is a scope condition on the method, not evidence that prophecy is unsound (Q12). ## Stuttering: matching different internal step counts The clock example connects a 24-hour counter to an hour/minute clock by inserting 59 steps that leave the original hour unchanged. A stuttering variable stores which action/context is being expanded and a value that advances toward a bottom value. Despite the name decr, the example’s order can use j+1, initial 1 and bottom 59. A refinement expression recovers the minute from the auxiliary state. PreStutter requires a predicate equivalent to the chosen action’s actual enablement; otherwise it could start an unfinished expansion of an action that cannot run (Q13). PostStutter and PreStutter insert at least one step; MayPostStutter and MayPreStutter permit zero. Correctness needs a countdown closed in its domain and reaching bottom from every domain value, a valid initial countdown on reachable original actions, and correct enablement for the pre form. StutterConstantCondition expresses finite reachability of bottom through a recursive closure over Nat. The alternative version is justified for finite Sigma. Replacing Nat and Sigma with finite TLC domains checks those instances only (Q14,C2). There is an actual paper/archive difference. Figure 16 sets MayPreStutter’s first countdown to decr(initVal), whereas the retained root Stuttering.tla sets it to initVal. A static trace with bot=0, initVal=1, decr(j)=j−1 therefore adds one pre-action step in the printed version and two in the archived version. This concerns the exact extra-step count when initVal differs from bot; it does not by itself refute auxiliary preservation or the snapshot example, which uses MayPostStutter. The archive comment also says “one fewer” while giving 42 as both the original and May operator example count. Do not assume all embedded Stuttering copies are identical to this root file (Q13,C2,D1). Section 5.4 treats a different problem: an implementation whose original variables halt may need to represent an abstract behavior with infinitely many internal steps. A history counter on an added unchanged-vars action, plus weak fairness for that auxiliary action, supplies infinitely many hidden steps. This is distinct from accidentally making an ordinary countdown infinite. Section 5.5 retains the original liveness conjunct and states preservation of machine closure for the described stuttering construction (Q15). ## Snapshot case: assumptions and proof structure The generic linearizable-object specification uses BeginOp, DoOp and EndOp with visible operation interfaces and hidden object/internal state. Type and closure assumptions establish the legal operations and results; weak fairness describes eventual internal execution and return. The snapshot specialization has disjoint logical Readers and Writers, a nonempty value set with an initial value, and a register per writer. One physical process may act in both logical roles. These are atomic shared-memory specifications, with no network failure, crash recovery, weak-memory or Rust implementation model (Q16). The example simplifies the unbounded-storage Afek snapshot algorithm. Each atomic register contains a value paired with an unbounded write number, so repeated writes never look identical. A reader collects registers twice, in arbitrary order, and returns only when the tagged collections agree. The omitted helping mechanism in the full algorithm is what would ensure termination despite interference; this simplified reader can retry forever. The paper explicitly states that only safety is satisfied (Q17,C3). A direct state mapping to the usual linearizable snapshot fails. A reader can collect an old register value, a writer can install a new value, and the reader can still finish with the old snapshot. Its abstract read must occur before the write, but the original state then lacks the future information needed to choose that point. The authors move the hard prophecy construction to a more permissive abstract specification, NewLinearSnapshot. It records for each active reader the sequence of memory values during that read and chooses the returned member at completion. This reformulation gives the implementation a simpler history-only connection to the intermediate specification (Q18). NewLinearSnapshotPS predicts which positive sequence index each reader will return. It adds an auxiliary step after BeginRd if index 1 is predicted, and after a write for each reader whose newly appended memory value is the predicted one. A countdown set removes one chosen reader at a time; its refinement expression assigns the corresponding atomic abstract read to those added steps. The displayed module asserts separate safety and full-spec refinement theorems. Its assumptions include StutterConstantCondition over SUBSET Readers with one-element removal; that condition must hold, so it cannot silently be extended to an infinite reader set containing an infinite countdown subset (Q19,Q20,C5). AfekSimplifiedH instead records the memory sequence h for each active reader. BeginRd starts it, writes append to active histories, successful read completion clears it, and failed retries retain it. The mapping uses the first component of each tagged register for abstract memory, h for rstate, and wrNum/interface/tag relationships for abstract writer state. Figure 27’s final statement is exactly “theorem SpecH ⇒ NLS ! SafeSpec”. This is a safety target, even though some surrounding prose and a retained source comment loosely refer to the full Spec. No general liveness result for the simplified algorithm follows from that prose (Q21,C4). ## Evaluation and released model boundaries The paper reports the final theorem checked by TLC in about ten hours on a circa-2012 laptop, using two readers, two writers, two register values, reader/writer symmetry, a state constraint of at most three writes per writer and two workers. This is a finite, constrained example check. No state count, memory use, scaling sweep, repeated-runtime distribution or unbounded mechanized final proof is supplied. Some local algebraic obligations have displayed TLAPS proofs, such as Next/Nxt equivalence; the final refinement theorems in the selected source files have no accompanying TLAPS proof (Q22,C4,C5). The two retained shipped AfekSimplifiedH models use the same 2/2/2 reader/writer/value cardinalities, SpecH, TypeOKH and NLS!SafeSpec. Model_1 replaces Nat with 0..2 and constrains wrNum[i]<2; Model_2 uses 0..3 and wrNum[i]<3. Each defines symmetry as permutations of writers only. These retained settings differ from the prose’s reader-and-writer symmetry and at-most-three-writes description. Strict wrNum<3 permits completed initial-state transitions only while the counter is below 3; it is not an exact encoding of allowing the third increment while remaining inside the state constraint. Without the unread historical logs/configuration, neither file can be identified as the reported ten-hour run. The observations qualify source correspondence; no rerun discrepancy is claimed (C6–C9,D2). ## Contribution to the requested topics This is directly relevant to proving concurrent/distributed systems correct in TLA+: its concrete value is choosing additional proof state without restricting the system’s original behaviors, checking intermediate prophecy/countdown conditions, and separating safety from progress. It supplies substantial worked specifications and a concurrent snapshot refinement, rather than an empirical comparison of tools. It contains no Verus, verified Rust or LLM experiment. Possible applications to specification/proof agents are reader proposals: require the hiding-equivalence obligation, preserve fairness and parameter assumptions, distinguish finite model checks from general proofs, and record paper/source differences. An agent that merely obtains a passing refinement implication could have strengthened away required behaviors or proved only safety. This paper explains the mathematical obligations such an evaluation should expose; it does not measure agent performance.
    • limits: Temporal hiding equivalence;prophecy reachability/injection/dependency obligations;terminating countdown/correctenablement;originalfairness;atomicsharedmemory/unboundedtags;simplifiedreadmaynotterminate;finiteconstrainedTLCnotunboundedproof;paper/archiveandmodelcorrespondencedifferences.
    • how much was read: most of it read
    • source; notes: connecting different descriptions of the same behavior
    • record id: auxiliary-variables-in-tla-2017
  • Dijkstra Monads for Free (2017)
    • what: The paper derives a weakest-precondition generator automatically from a simple definition of an effect such as state or exceptions. A weakest precondition is the least that must hold before code runs for its result to be correct. With this, F* can generate proof obligations for Z3.
    • number: no experiments, runtimes or proof sizes reported
    • number: No success rate, runtime, proof size or person-hours reported
    • number: Examples: state increment, division with exceptions, rollback state, dynamic allocation, information flow, continuations
    • limits: It is sound for total correctness (the code terminates and is right) in the paper’s calculus. Humans write the specification. In the functional-interpretation route it works only for terminating code. An information-flow policy needs a separate argument.
    • how much was read: most of it read
    • source; notes: Dijkstra Monads for Free; notes: Dijkstra Monads for Free; notes: Concrete problem records
    • record id: dijkstra-monads-for-free-2017
  • Girault et al. MPC (2017)
    • title: Monotonic Prefix Consistency in Distributed Systems
    • what: Defines Monotonic Prefix Consistency (MPC) for replicated lists, gives a centralized toy implementation whose traces satisfy MPC, and proves that no convergent distributed implementation under asynchronous message delivery, availability, and the paper’s observability can be strictly stronger than MPC. Formalizes implementations as total update/query/message handlers, asynchronous broadcast/receive executions with causal delivery and fairness, and traces that record per-site query order/results plus an unordered set of writes. MPC requires per-site monotone reads, pairwise prefix-compatible reads across sites, and read values drawn from writes. Lemmas establish update/query availability, invisible-read deletion, fair execution limits, and convergence extension; induction then realizes every finite MPC trace and a limit argument realizes infinite traces. The paper compares MPC with causal and strong consistency and notes its observability makes MPC and strong-consistency traces indistinguishable.
    • number: MPC monotonicity/prefix/consistency conditions
    • number: finite and infinite trace construction
    • number: eventual-consistency convergence definition
    • number: all messages eventually delivered
    • limits: Assumes broadcast communication (peer-to-peer is encoded), all messages eventually delivered in infinite executions, total handlers (availability), list updates/queries with updates split from queries, unique write values (timestamps can enforce this), and a trace abstraction that hides write origin and write/query real-time order. Convergence means every write is absent from only finitely many queries. The impossibility does not directly cover operations that are both reads and writes, origin-sensitive traces, or probabilistic settings; the MPC implementation is centralized for simplicity.
    • how much was read: most of it read
    • record id: girault-et-al-mpc-2017
  • Gomes et al. SEC Isabelle (2017)
    • title: Verifying Strong Eventual Consistency in Distributed Systems
    • what: Builds a reusable Isabelle/HOL framework that formalizes strong eventual consistency (SEC), an asynchronous unreliable causal-broadcast network, and three operation-based CRDTs: Replicated Growable Array, Observed-Remove Set, and increment-decrement Counter. The abstract convergence theorem proves that distinct happens-before-consistent operation lists with the same set of operations yield the same state when concurrent operations commute, while a separate no-failure condition gives progress. The network locale has six axioms covering unique node histories, delivery cause, local delivery, globally unique message IDs, causal delivery, and valid broadcast operations; messages may be delayed, reordered, dropped, or nodes may crash permanently. RGA proof models immutable element IDs, tombstones, insertion ordering, causal validity, and proves concurrent operations commute and application never fails. ORSet uses add IDs and remove sets of observed IDs; Add/Remove commute only under a proved independence condition. Counter operations commute unconditionally. The framework is executable via Isabelle code generation; one counter implementation ran over TCP, but detailed performance/fault-tolerance evaluation was left for future work.
    • number: 3 CRDTs verified
    • number: 6 network axioms
    • number: ~620 lines network, ~380 convergence, ~775 RGA, ~270 ORSet, ~55 Counter
    • number: ORSet proof about four hours; Counter minutes
    • limits: Network assumptions are axiomatic: finite totally ordered per-node histories, unique events/IDs, causal delivery for dependencies, and valid-msg predicates supplied by the algorithm. The model uses crash-stop permanent node failure, not recovery, and does not model overlay implementation, timing, or resource limits. RGA retains tombstones; garbage collection is explicitly out of scope. The correctness claims are for operation-based CRDTs satisfying the five SEC locale obligations, not arbitrary distributed data types. Executable extraction demonstrates computability rather than performance.
    • how much was read: most of it read
    • source; notes: papers and boundaries
    • record id: gomes-et-al-sec-isabelle-2017
  • Paxos Made EPR (2017)
    • title: Paxos Made EPR: Decidable Reasoning about Distributed Protocols
    • what: The paper transforms Paxos-family models so that checking a human-supplied proof falls in EPR. EPR is a first-order fragment where satisfiability is decidable (an algorithm always answers). It checks proofs. It does not discover invariants.
    • number: Six variants: Paxos, Multi-Paxos, Vertical Paxos, Fast Paxos, Flexible Paxos, Stoppable Paxos
    • number: Verified six protocol variants with EPR transformations
    • number: Z3 experiments repeated 10 times, 300s timeout, Linux Core-i7 1.8GHz
    • number: EPR verification conditions solved in a few seconds with no timeouts; semi-bounded runtimes grew with rounds; unbounded Z3 diverged
    • limits: Z3 did not terminate on unbounded checks of the original models. The URL of the original artifact returns 404, and the review notes found no verified copy.
    • how much was read: most of it read
    • source; notes: Paxos Made EPR
    • record id: paxos-made-epr-2017
  • Alloy meets TLA+: An exploratory study (2016)
    • what: # Alloy meets TLA+: An exploratory study (authored by agents unless marked 🧑) Macedo and Cunha compare a manually embedded hotel locking model in Alloy and TLA+, then measure checking costs with Alloy Analyzer 4.2/MiniSat and TLC 2.08. This is a one-example exploratory study. Their scope is explicit: “using a concrete example” (§1, PDF p. 2, Q6). No general translator, equivalence theorem, implementation proof or named theorem is presented. The source is arXiv1603.03599v1, 11 March2016, 14pages; a further publication venue was not established. ## What the model assumes and checks (authored by agents unless marked 🧑) The front desk is disconnected from room locks. A lock accepts its current key or the next key in its room’s ordered, disjoint keypool; accepting a newer key invalidates the old one. Guests keep keys after checkout. Initially rooms are vacant, guests hold no keys and the front desk’s last-issued key equals the lock’s current key (§§2–2.1, PDF pp. 3–5, Q7–Q11). The authors describe the retained-key behavior directly: “allows the guest to keep the room key” (§2.1, PDF p. 5, Q11). The finite model has no fairness constraint (§3.1, PDF p. 9, Q22). The prose says a guest should enter only its own room. The printed assertion is narrower: “(Entry[t, t’, g, r, k] and some FD.occupant.t[r]) implies g in FD.occupant.t[r]” (Figure 1, PDF p. 4, Q10). It tests entry into an occupied room and allows entry into an empty room. The TLA+ property has the same nonempty-occupant guard (Figure 3, PDF p. 7, Q17). The experiment checks safety; discussion of finite-trace liveness pitfalls is not a liveness evaluation. The counterexample has five states: initialization; g0 checks into r1 with k1; g0 checks out; g1 checks into r1 with k2; g0 enters using k1 before g1 first uses k2 (Figure 2, PDF p. 6, Q15; §2.2, PDF p. 5, Q14). It demonstrates the delay between issuing a fresh key and updating a disconnected lock. The proposed restriction is to “assume that guests enter the room immediately” after check-in (§2.2, PDF p. 5, Q14). NoIntervening therefore changes allowed environment behavior. The authors report no counterexample after adding it in the checked models; this is not a verified implementation repair or an unbounded Alloy proof. The printed models and prose contain a reproducibility mismatch. Figure 1 includes NoIntervening and prints “check NoBadEntry for 3 but 30 Time” (Q10), while §2.2 describes 3 elements/5 Time and a counterexample (Q13), and §4 calls Figure 1 an n = 4/t = 30 model (Q30). Figure 3 also includes NoIntervening in Spec, while Figure 4 shows a counterexample (Q17–Q18). The evaluation explicitly ran with and without the restriction (Q29); the printed restricted listings alone should not be described as producing those unrestricted traces. ## What the embedding exposes (authored by agents unless marked 🧑) The study distinguishes TLA+ expressiveness from TLC’s executable subset (§3, PDF p. 6, Q16). Alloy’s static structures range over possible assignments, while a TLC constant assignment fixes one structure. To preserve the intended search, Room, Guest and keypools are initialized nondeterministically as variables and then held unchanged. Fixing exactly 3 rooms and 3 keys misses this bug because a room needs two spare keys for the successive check-ins (§3.1, PDF p. 8, Q19). This is a concrete example of a checker returning no counterexample after the search universe has been narrowed incorrectly. Alloy’s explicit Time ordering creates exact trace scopes. The authors warn that “there is no guarantee that counter-examples occurring” in smaller traces recur at larger exact scopes (§2.2, PDF p. 5, Q13). They therefore check every scope through t and accumulate the cost. A bound below 5 misses this bug. These are finite trace checks over finite key/room/guest universes, not a parameterized proof. The TLA+ version encodes Alloy facts through TypeInv in Next. The authors separately report checking TypeInv as an invariant and observing preservation by the actions (footnote 2, PDF p. 9, Q23); this is a reported finite-model check. TLC’s enumeration/order/next-state requirements and relational encoding issues constrain the manual embedding (§3.1, PDF pp. 8–10, Q20–Q24). No general derivation algorithm is supplied. Stuttering affects what counts as an observed event. When a registered key is used again, Entry changes no variable: “TLC will not recognize such” steps, “identifying instead a stuttering step” (§3.2, PDF p. 10, Q25). The box-action NoBadEntry accepts stuttering independently of its inner action condition. The paper leaves general action-semantic correspondence unresolved (§5, PDF p. 14, Q37). This record identifies that limit; it does not construct a reachable unauthorized stuttering entry or refute the restricted model. NoIntervening is rewritten from a constraint on three Time instants to a state predicate Post plus the next Entry; stuttering remains allowed and no fairness is added (Figures 1/3, Q10/Q17;Q22/Q27). Deadlock reporting was disabled for finite key exhaustion and state-preserving Entry (§3.2, Q26). No progress or deadlock-freedom result follows. ## What was measured (authored by agents unless marked 🧑) The study used a 1.8 GHz Intel Core i5, 4 GB, OS X 10.10, Alloy Analyzer 4.2 with MiniSat and TLC 2.08. Tests ran “multiple times”; no repetition count, variance or raw trials are supplied (§4, PDF p. 11, Q29). TLC breadth-first and depth-first searches were tested, with depth-first limited to 100. Thus the paper’s general description of unlimited TLC trace length must not be applied to every plotted curve. Figure 5 contains six panels and five series: TLA BF, TLA DF, Alloy, TLA En, Alloy En (PDF p. 12, Q31 and figure-evidence.json). Panels a/b vary n with Alloy t = 30; c/d use the different exact universe; e/f vary t with n = 4. The vertical axis is logarithmic seconds. All panels were inspected; no exact point timings were inferred from raster curves. No error bars or raw trials are provided. Here n denotes exact ordered-key count and maximum room/guest counts. Alloy’s time at t aggregates checks for all scopes 1 through t; BF finds a shortest witness directly (§4, Q30). The authors report that the Analyzer finds the n = 4 counterexample at t = 5 “in less than a second in contrast to TLC’s 415 seconds” (§4, PDF p. 11, Q30). The sentence does not identify which TLC search mode the 415 seconds denotes. This is verification runtime on this model and historical setup, not application latency or a general tool speedup. Generating static configurations is expensive. The original model has 776 initial states at n = 3 and 18,960 at n = 4. A second model fixes exactly n rooms and n guests and uses n + 2 keys, giving 108 and 960 states. The paper explicitly says these universes “are not directly comparable” at the same n (§4, PDF pp. 12–13, Q32–Q33). Do not treat the change as a semantics-preserving reduction of the original universe. A preliminary hybrid uses Alloy to enumerate initial structures and TLC to check each fixed structure. Alloy’s symmetry breaking reduces 18,960 to 520 representatives for n = 4, generated in “less than 2 seconds” (§4, PDF p. 13, Q34). Disabling symmetry recovers 18,960. The partition loses the global shortest-counterexample guarantee and state sharing. For counterexample timings the authors “considered a” portion of the initial states after measuring the fraction that produce a counterexample; neither fraction nor portion/order is supplied (§4, Q35). With NoIntervening they consider all initial states. The hybrid improves some TLC curves; its gains over pure Alloy “are not so evident” (Q35). No proven general translator or symmetry-preservation result accompanies this preliminary comparison. ## What it adds to the requested topic (authored by agents unless marked 🧑) The direct contribution is a detailed historical Alloy/TLA+ modeling comparison with a complete small example and measured checking costs. Distributed algorithms motivate systems with rich structures and dynamics (§1, Q3), but hotel locking is the sole evaluated case. No Verus, verified Rust or LLM experiment appears. For evaluating LLM-written specifications, I infer concrete checks from this example: compare exact versus maximum cardinalities; read the property’s guard; separate an implementation repair from an environment restriction; check event/stutter correspondence; distinguish checked invariants from imposed constraints; compare trace coverage and cumulative timing; retain sampled-state caveats. These are reader-derived evaluation lessons, not measured LLM results. The authors’ own conclusion keeps the main performance limit explicit: “the obvious caveat of the bounded search space” (§5, PDF p. 14, Q37). ## Evidence and limits of this read (authored by agents unless marked 🧑) Read all 649 layout-text lines, all 14 pages, every printed Alloy/TLA+ definition/configuration, five figures including six Figure 5 panels, Table 1 and all 11 references. Inspected seven contact sheets and the fullsize plot page. The bundle retains 38 literal line/character/page-anchored excerpts, 17 reader diagnostics, numeric evidence, visual evidence and hashes. combined.quote-source.txt is the staging source; source_files contains path strings and raw hashes are separate. No separate model/benchmark archive URL was identified in the paper or obtained. No author code, checker, solver or prover was executed, and no serialized scientific/model/results data were loaded. Results are author-reported and statically inspected, not independently reproduced. Historical language/tool claims should not be projected onto current versions.
    • limits: Disconnected front desk/locks; finite ordered disjoint disposable-key pools; guests retain keys after checkout; no fairness. Printed property checks only occupied-room entry. NoIntervening restricts environment behavior. Bounded exact Alloy trace scopes; finite TLC universes and depth-first limit 100. General translation and stutter/event correspondence unresolved. Printed scope/variant mismatch retained.
    • how much was read: most of it read
    • source
    • record id: alloy-meets-tla-an-2016
  • Ivy repository (2016)
    • title: Ivy: Safety Verification by Interactive Generalization
    • what: Ivy is a research tool for interactive development of protocols and correctness proofs, with interactive visualization of automated proofs and a human/tool workflow for exposing errors.
    • number: Bounded verification about 10 transitions in a few minutes
    • number: Pages 614-630
    • limits: README is brief and points to the website for details.
    • how much was read: most of it read
    • source; notes: tools
    • record id: ivy-repository-2016
  • Multi-Paxos TLAPS (2016)
    • title: Formal Verification of Multi-Paxos for Distributed Consensus
    • what: # Formal Verification of Multi-Paxos for Distributed Consensus (authored by agents unless marked 🧑) Saksham Chand, Yanhong A. Liu and Scott D. Stoller. The original paper appeared at FM 2016, pp 119–136, DOI 10.1007/978-3-319-48989-6_8. This record reads the 37-page corrected and extended arXiv:1606.01387v4, dated 11 November 2019, classified cs.DC on its first page. The inventory’s 2016 year identifies the original work; it does not date the corrected version read here (Q1,Q45; arxiv.html). The contribution is a small TLA+ specification of Multi-Paxos and its preemption extension, an author-reported TLAPS proof of per-slot agreement, and concrete strategies for managing the much larger proof. Two qualifications matter. The authors explicitly retract the earlier completeness claim: “The claim of a complete proof in [7] was incorrect” (§1 p2, Q3), explaining a PTL backend bug and their replacement type-invariant proof. Separately, this read finds inconsistent maximum axioms in the printed appendix and pinned proof files as written (Appendix C p29, Q49,Q59,Q63). Thus the record preserves the corrected checking report but does not treat checker acceptance under those retained assumptions as independent certification of the assumption-free theorem. This is a mathematical assumption problem, not an observed execution failure or a counterexample to Multi-Paxos agreement. ## Reading and evidence scope Read all 37 PDF pages in extracted text and rendered images: sections 1–7, all six figures, both numeric tables, all 26 numbered equations, acknowledgments, all 63 reference entries, and Appendices A–C containing the specification, invariants and hierarchical proof. The figures are algorithm/proof listings and comparisons, not statistical plots. The two PDFs, one from the local inventory and one freshly fetched from arXiv, are byte-identical. The local PDF is the corrected v4, not the 2016 proceedings text. Fetched the author-linked DistAlgo/proofs repository’s metadata, commit and recursive tree. The pin is fb4a727ed8fab39197d9a20ed066d21abbb83573, last commit 4 November 2019. Read its full README and selected plaintext specification, assumption, type-invariant and final-theorem regions of the improved Multi-Paxos/preemption modules, plus the historical FM16 TypeOK regions. The README distinguishes these versions and says improved proofs were checked with TLAPS 1.5.6 (Q56). Downloaded Basic Paxos baseline and historical modules provide retained source context; this is not a whole-repository or whole-module audit. The explicit excerpt/range inventory is in source-scope.json. Also read the complete official issue 40 body describing the coalescing bug (Q66); metadata says opened 1 April 2017 and closed 17 May 2018. Closing an issue does not identify the fix commit or certify every installed tool version. No author code, model, TLAPS, TLC, SMT solver or proof assistant was executed or imported. No serialized data/model/checkpoint was loaded. Reader checks use file hashes, literal source slices, arithmetic and symbolic reasoning. Raw Git files retain their bytes; .lf.txt files are identified newline-normalized derivatives for character and LF-line quote pointers. The PDF extraction renders □ as 2, primes as 0 and some negated existential/membership symbols unusually; rendered pages were used to interpret the formulas. quotes.json retains extraction bytes, including such artifacts. ## The model and the exact theorem The system has proposer, acceptor and learner roles, which may be colocated. Constants describe proposers P, acceptors A, quorum family Q and possible values V. Ballots B and slots S are natural numbers. Membership and the quorum family are fixed: dynamic reconfiguration is excluded. The sole stated quorum condition is Q ⊆ SUBSET A and pairwise nonempty intersection. Majority, tree or matrix quorums can instantiate it once that condition is established; the paper does not construct or evaluate those alternatives (Q6,Q13,Q19). The state contains the set msgs of every message ever sent, proposer ballots pBal, each acceptor’s highest seen ballot aBal, and aVoted, a set of ballot-slot-value records retaining the highest voted ballot for each slot. Init uses no messages/votes, proposer ballot 0 and acceptor ballot −1. Next chooses one proposer or acceptor phase. Spec = Init ∧ □[Next]_vars permits an action or stuttering at each step (Q13–Q19). The messages-as-history abstraction lets processes select any previously sent message, repeatedly and in any order. An unhandled message models arbitrary delay or loss; repeated handling models duplication. Crashes are modeled by not scheduling the crashed process, and recovery resumes its retained state. The authors require “all state (vars) is stored in stable storage” (§3.3 p11, Q20). The model has no Byzantine message fabrication, volatile-state reset, implementation of durable storage, or explicit network delivery queue. This is a safety abstraction of benign failures. There are no fairness or eventual-delivery clauses in the displayed Spec. Repeating Init forever is a valid behavior through UNCHANGED vars and never chooses a value. This reader witness demonstrates the absence of decision progress, without challenging agreement. A quorum of functioning processes and delivery assumptions would matter for liveness; no such liveness theorem is established here (Q9,Q15,Q19; math-witness.json). The target is Spec ⇒ □Safe, where Safe means any two chosen values for one slot are equal. The paper identifies C1 proposed-value validity, C2 agreement and C3 learner correctness, then says C1/C3 are excluded from the formal proof; §3.3 and §4.8 discuss them informally (Q5,Q22,Q33). There are no explicit learner variables/actions. Validity means a chosen slot/value occurred in a protocol 2a proposal, not that a value came from an external client or satisfied an application invariant. Equations 24/26 use sent although the state variable is msgs; the record treats this as the printed informal derivation, not a checked new theorem. The precise Chosen definition used in the proof is ∃b ∈ B: ∃Q ∈ Q: ∀a ∈ Q: VotedForIn(a,b,s,v). VotedForIn witnesses a sent 2b message with that ballot and slot/value. The introductory equations 3/4 place ∃b inside ∀a, allowing different ballots for different acceptors. Those predicates differ; use equations 10–12 and Appendix B for the actual theorem (Q6,Q23,Q48). A separating predicate valuation in math-witness.json makes the difference explicit, without claiming a reachable protocol counterexample. ## Minimal algorithm changes Basic Paxos carries one latest accepted ballot/value pair. Multi-Paxos carries a set of ballot-slot-value records in each promise. Phase1a sends a ballot. Phase1b responds only to a strictly higher ballot, returning its voted-record set and recording the promise. Phase2a waits for same-ballot promise replies covering a quorum and sends at most one 2a message per ballot. It selects the maximum accepted ballot separately per slot, retaining that slot’s value, and adds new slot/value pairs. Phase2b accepts a ballot at least its promise, sends a 2b reply, and replaces voted records only for the slots in that proposal (Figures 2–5, Q14–Q18). MaxBSV filters the voted records to maximal ballots per slot; MaxSV drops ballots; UnusedS finds absent slots; NewSV chooses a set of unused-slot/value pairs with no duplicate slot carrying different values; PropSV combines old and new pairs. Ballots are shared across slots, and old unfinished slots can be reused. The authors explain that this is more involved than separately running independent Basic Paxos instances (Q15,Q17). NewSV has no explicit nonemptiness, finiteness or client-input requirement. The empty set satisfies its uniqueness predicate. CHOOSE denotes a fixed mathematical choice for the same argument, not a newly sampled nondeterministic result each time. The formulas are useful abstractions for agreement, but do not by themselves ensure an executable finite batch or useful new work. Finite msgs does not imply finite message payloads (Q17,Q47; math-witness.json). Preemption adds an addressed reply containing an acceptor’s highest ballot when it rejects a proposer ballot. A proposer receiving a strictly higher preempt ballot updates pBal above it. Phase1a then sends pBal, and the two acceptor actions have extra rejection branches (Figure 6/Appendix A, Q34,Q35,Q47). In Phase1b equality also enters the else branch, although the prose often says lower ballot. The proposer’s strict-higher guard prevents equality from raising pBal. Two source differences constrain exact correspondence. The printed NewBal requires only b>b2; the pinned NewBallot also excludes ballots already used by a 1a message, matching §5.1’s fresh-ballot explanation. Conversely, the pinned non-preemption Phase1a omits the no-prior-1a guard displayed in Figure 2. Both retain the global no-prior-2a-per-ballot guard. These differences are documented, not silently normalized or labeled agreement violations (Q14,Q35,Q36,Q47,Q57,Q62). Actual software must allocate ballots, for example ordered counter/process-identifier pairs, rather than inspect a global history oracle. Reconfiguration, message/state reduction and failure detection are omitted. A 1b reply can contain votes for every previously used slot. There is no verified Rust implementation, code refinement or operational throughput experiment in this paper (Q21). ## Invariants, decomposition and final argument Inv conjoins TypeOK, AccInv and MsgInv. TypeOK constrains every message/function/record field; the corrected preemption version additionally requires finite msgs. AccInv relates each acceptor’s promise and current voted records to the historical 2b votes: stored records were actually voted, every historical vote is covered by a same-slot record at least as high, and no vote lies above the current same-slot maximum (Q25,Q26,Q48). MsgInv1b records the sender’s promise, actual historical votes in its returned set, and absence of votes between that slot’s stored maximum and the promised ballot. MsgInv2a says every proposal is SafeAt its ballot, a message has at most one value per slot, and there is only one 2a message per ballot. MsgInv2b ties each vote to a matching 2a message and bounds its ballot by the acceptor’s highest seen ballot (Q27,Q28). SafeAt(b,s,v) says that for every lower ballot, some quorum consists of acceptors that voted v or have promised above that ballot and never voted there. WontVoteIn expresses the latter alternative. VotedInv carries SafeAt from proposals into votes; VotedOnce states same-ballot/same-slot votes have the same value, even from different acceptors. Their role is concrete: at equal chosen ballots use VotedOnce; at unequal ballots intersect the chosen quorum with the SafeAt quorum. The common acceptor’s old vote excludes WontVoteIn, leaving equal values (Q24,Q50,Q55). The proof first establishes Init ⇒ Inv and Inv ∧ [Next]_vars ⇒ Invâ€Č, with separate action cases and an explicit unchanged-state case. PTL then derives Spec ⇒ □Inv and transfers Inv ⇒ Safe to the temporal Safety theorem (Q29,Q52–Q55). The final temporal QED is present; its presence still does not prove the assumed mathematics consistent. The reusable method separates unaffected old elements from each action’s new message or voted-record increment. Invariance lemmas preserve old VotedForIn/SafeAt facts; the new element is proved from the sending action and local invariants. Conjuncts and actions form a mechanical decomposition, while difficult bounds and witnesses require manual facts. The paper illustrates this fully for Phase1b and MsgInv and shows the longer Phase2a proof in Appendix C (Q30,Q31,Q51,Q54). Proof syntax matters to performance. A common acceptor voting both values in the equal-ballot case is supplied explicitly; the authors report about 90 seconds reduced to a few milliseconds, calling it a 10,000× local speedup. Replacing direct record membership by an existential record with field equalities made another proof proceed after the original stalled for one or two minutes. These are local development observations, with no repeated-run distribution or uniform ablation (Q32). Tuple access is a concrete proof-engineering choice, not evidence of an algorithm runtime speedup. ## The disclosed checker bug and the remaining assumption problem The authors report that historical PTL coalescing could “prove” a primed state formula from its unprimed assumption outside a valid temporal context. It incorrectly accepted TypeOKâ€Č under TypeOK ∧ [Next]_vars. The official issue’s example falsely preserves xyz=0 while Next permits increasing xyz. Choosing increment 1 from xyz=0 gives xyzâ€Č=1, refuting that preservation claim symbolically (Q36,Q66). Historical FM16 modules retain PTL at primed message-type leaves; improved excerpts instead give explicit action proofs (Q60,Q64,Q65). The repair proves type preservation for all phases. Preemption needs a fresh larger natural ballot to exist. With finite msgs, the used 1a ballots form a finite set T; max(TâˆȘ{received ballot})+1 supplies a larger unused witness. The authors added IsFiniteSet(msgs), proved preservation under message addition and supplied this witness. They report initial TypeOK proof growth 54→93 lines and 75→138 lines for the two variants; subsequent improvements reduce those to 54 and 77 (Q36,Q37,Q52). A separate issue remains in the retained text. Appendix C calls two axioms “straightforward consequences” but writes MaxInSet as ∀S∈SUBSET N: Max(S)∈S (Q49). Substitute S=∅: it asserts Max(∅)∈∅, false for every CHOOSE result. The pinned source writes the domain as (SUBSET Nat) \ {}, which subtracts no elements and still includes ∅ (Q59,Q63). Removing the empty set as an element would require {{}}. That change alone would still leave unbounded infinite subsets: applying MaxInSet and MaxOnNat to Nat gives a natural maximum k, but k+1 is a larger natural. A sound maximum lemma needs nonempty finite or bounded domains and proof that each use meets the restriction. These are static mathematical witnesses to inconsistent assumptions as written, not TLAPS runs, discovered new protocol executions, or an assertion that every leaf exploited inconsistency. The retained files cannot alone support an assumption-free machine-certification claim. Agreement may be true and the intended invariant argument may be repairable, but repairing and replaying it is outside this literature read. The disclosed PTL repair does not address these maximum axioms. This distinction is particularly useful when evaluating automated proof agents: green obligations and completed syntax must be accompanied by an audit of explicit axioms and the actual target. ## Evaluation and quantitative evidence The evaluation compares Basic Paxos, Multi-Paxos and Multi-Paxos with Preemption, plus older incomplete and corrected/improved proof variants. It measures text size, proof-tree structure, lemma reuse, obligations and proof-checking cost, not network performance or application throughput. Table 2 specifies a four-core Intel i7-4720HQ at 2.6 GHz, 16 GB RAM, 64-bit Ubuntu 17.10 and TLAPS 1.5.6. Earlier elapsed times from 1.5.3 are marked separately. No raw timing logs, repeat counts, variance or matched cross-tool benchmark are provided (Q40–Q42). The corrected new rows report specification lines excluding comments of 52, 55 and 74; proof lines 310, 787 and 831; obligations 239, 779 and 825; total CPU seconds 40, 175 and 180; total elapsed seconds 14, 51 and 90. CPU time and elapsed time are distinct; the total CPU values are close to the headline “about 3 minutes,” whereas the elapsed values are 51/90 seconds. Adding Multi-Paxos slots costs only three specification lines but 477 proof lines and 540 obligations; adding preemption costs 19 specification lines, 44 proof lines and 46 obligations. The per-slot data structure creates most of the proof expansion (Q40,Q41). The new proof trees have maximum level 10 and degree 17, against 7 and 3 for Basic Paxos. Multi-Paxos/preemption use five/six invariance lemmas 32/35 times and three proofs using set increments each. §4.6’s five lemmas used 27 times describes an earlier count; Table 2 provides the updated reuse counts (Q31,Q41). Reflowed appendix counts, including 528 proof lines excluding comments, are layout alternatives, not another method or independently smaller proof. The three improvements factor message predicates, merge similar unchanged-state cases and remove leaf scaffolding TLAPS can establish automatically. Reported reductions for preemption include 75 lines from predicate factoring, 27 from merged cases, 110 from about 25 unnecessary-obligation instances and 61 from 22 TypeOK instances. The full repaired proofs shrink 1049→787 and 1117→831 lines; those are 25%/26% reductions from the repaired versions. Old incomplete rows marked ^^ are not valid proof-performance baselines (Q3,Q37–Q41). Table 1 gives improved TypeOK elapsed times 8/25 seconds; Table 2 gives 7/24. Their old preemption TypeOK elapsed entries also differ, 21 versus 22. Preserve these printed differences rather than inventing a run-variance explanation. numeric_tables.json retains every metric, alternate count and footnote marker. The report that adding preemption took less than an hour explicitly excludes TypeOK; it cannot be used as total authoring time for the corrected proof (Q34,Q37,Q41). ## Relationship to the requested research topics This is directly useful for TLA+ and formal verification of distributed protocols: concrete fault abstraction, per-slot agreement, quorum reasoning, stronger invariants, hierarchical proof feedback, old/new-set decomposition and sensitivity to formula representation. Its strongest evaluation lesson is the explicit correction history, reinforced by the separate maximum-assumption findings in this read. The work contains no Verus, verified Rust or LLM-agent experiment. Transfer to those topics is a reader proposal: preserve the exact property and fault model; measure changes in executable specification separately from proof scaffolding; give agents small action/conjunct obligations with explicit contexts; distinguish finite-instance testing from parameterized proof; and check axioms, omitted obligations, tool versions and source correspondence before reporting success. No agent success rate or Rust implementation result follows from this paper. Related-work proof-size comparisons with IronFleet, Verdi, EventML/Nuprl, EPR and other systems are author descriptions of differently scoped work, not controlled evidence that TLAPS is uniformly faster or requires fewer lines. The separate executable-program work in reference 45 reportedly found a safety violation missed by testing/model checking, but that example is cited rather than reproduced and verified here (Q43,Q44). Those leads can be followed as separate full reads.
    • number: Safety proof for Multi-Paxos
    • number: Proof strategies build on Basic Paxos
    • limits: Fixedmembership,intersectingquorums,naturalballots/slots,historicalmessages,stableallstateacrosscrashes,unfairstuttering. AgreementC2only; noformallyprovedC1/C3,liveness,clientvalidity,finitepayloadorimplementationrefinement. AuthorscorrectpriorPTLgap;readerfindsretainedmaximumaxiomsinconsistentaswritten;notindependentassumption-freesafetycertification. Noauthorcodeexecution.
    • how much was read: most of it read
    • source
    • record id: multi-paxos-tlaps-2016
  • Practical verification framework for preemptive OS kernels (2016)
    • title: A Practical Verification Framework for Preemptive OS Kernels
    • what: Presents a Coq-mechanized framework that models preemptive-kernel API correctness as contextual refinement from a practical C subset, with abstract specifications, concrete interrupt-aware semantics, a relational concurrent separation logic, and proof tactics. It verifies scheduler, timer interrupt, synchronization APIs and priority-inversion freedom in commercial ÎŒC/OS-II. The framework separates application state from kernel state, gives small-step sequentially consistent semantics for task continuations and x86-8259A interrupt state, and uses a high-level language with nondeterministic/configurable scheduler relation. Relational assertions connect concrete memory, abstract state and remaining abstract command; ownership-transfer invariants account for nested interrupt levels. A soundness theorem is proved by compositional simulation. PIF is stated using original task priorities and proved for a simplified ÎŒC/OS-II mutex under no nested mutex use; verification required minor defensive changes because contextual refinement quantifies over arbitrary clients.
    • number: about 1,300 C lines verified, 63% of frequently used APIs
    • number: 216,000 lines of Coq implementation/proofs; 5.5 person-years
    • number: Coq framework package about 216,000 lines and compilation about 16 hours on 3.6 GHz/32 GB machine
    • number: proof-script to verified-C ratio about 26:1
    • limits: The machine model is tailored to Intel 8259A-style interrupts and sequential consistency; adapting other processors requires new interrupt rules. The C subset excludes function pointers and virtual memory. Contextual refinement assumes arbitrary clients, unlike original ÎŒC/OS-II precondition assumptions, motivating code checks. PIF theorem assumes no nested mutexes, no deadlock and scheduler consistency. Task creation/deletion was unfinished. Proof effort and data-structure abstraction (bitmap waiting queues) are substantial.
    • how much was read: most of it read
    • record id: practical-verification-framework-for-preemptive-os-kernels-2016
  • Alloy MCA Verification (2015)
    • title: An Alloy Verification Model for Consensus-Based Auction Protocols
    • what: Builds a machine-readable Alloy model of Max-Consensus Auction (MCA) protocols, separating bidding and agreement mechanisms from policy choices, and checks convergence to conflict-free allocations. The model represents asynchronous bid and allocation vectors, timestamps, network topology, physical/virtual network mapping, policy predicates, and bounded message-processing traces. The authors optimize Alloy encoding by replacing ternary relations/integers with binary relations and custom value signatures. Assertions check eventual consensus across scopes; counterexamples show oscillation when bids are non-submodular and agents release/rebid subsequent items, plus denial-of-service via rebidding lost items.
    • number: 259K SAT clauses reduced to about 190K by abstraction changes
    • number: representative assertion runtime reduced from about one day to less than two hours
    • number: Result 1: consensus holds for checked policies except non-submodular utility plus release/rebid policy
    • number: Result 2 finds no consensus when rebidding on outbid items is allowed
    • limits: Finite Alloy scopes and SAT bounded analysis cannot establish unbounded correctness; checking SAT is generally exponential. Agents are intended to cooperate, and convergence requires no rebidding on already-lost items and generally submodular utilities. The attack analysis is model-level; preventing malicious rebids and larger instances are left open.
    • how much was read: most of it read
    • record id: alloy-mca-verification-2015
  • Automated and Modular Refinement Reasoning for Concurrent Programs (2015)
    • what: Introduces civl, a Boogie extension that proves multi-layer refinement of concurrent shared-memory programs. Cooperative yield semantics, mover-type automata, location invariants, linear permissions and modular ownership reduce preemptive concurrency reasoning to automated per-procedure obligations. A high-level atomic action is refined by a procedure whose paths contain exactly one implementing atomic block; other blocks preserve visible state. Mover types and the yield sufficiency automaton justify cooperative reasoning for sequentially consistent preemptive execution. Linear variables guarantee distinct thread identifiers or disjoint permission sets across threads. Location invariants are checked for sequential correctness and non-interference; modules own disjoint globals so quadratic checks are per module. A soundness theorem chains layers from safe high-level program to low-level implementation. Implementation infers verification conditions and atomic blocks, computes graph simulations in O(n·m), and supports variable hiding/data refinement.
    • number: 32 benchmarks, 17–539 LOC, total 20 s
    • number: GC ~2,100 Boogie LOC, six refinement layers, 60 s total
    • number: GC 54 s sequential/non-interference; remaining checks insignificant
    • number: yield-simulation algorithm O(n·m) in control-flow nodes/edges
    • limits: The paper focuses on sequential consistency and leaves weak memory models future work. Safety guarantee requires high-level safety, valid refinement, sequential/non-interference invariants, linear typing, pairwise commutativity, sufficient yields, and infinitely frequent yields on infinite executions. The full formalization is in a technical report. Modules require strict global-variable ownership. Location invariants cannot refer to other threads and can be incomplete. The approach verifies safety/refinement, not liveness or arbitrary functional properties.
    • how much was read: most of it read
    • source
    • record id: automated-and-modular-refinement-2015
  • Coq hierarchical coherence and speculative CPUs (2015)
    • title: Modular Deductive Verification of Multiprocessor Hardware Designs
    • what: A Coq proof that speculative processors, composed with a hierarchical MSI memory, implement sequential consistency. It is parameterized over the number of processors and caches. It is built from proofs of separate components.
    • number: 12,000 lines of Coq
    • number: 80% can be reused as-is for other inclusive invalidation protocols
    • number: MSI proof about 12000 lines of Coq; authors say 80% reusable for related inclusive protocols
    • number: arbitrary processor/cache counts and hierarchy levels
    • limits: It covers safety only. It verifies the Coq hardware description, not that synthesis preserves it. No person-time is given.
    • how much was read: most of it read
    • source; notes: Related work absent from the first pass: Modular Deductive Verificatio
    • record id: coq-hierarchical-coherence-and-speculative-cpus-2015
  • IronFleet (2015)
    • title: IronFleet: Proving Practical Distributed Systems Correct
    • what: It proves a replicated state machine (IronRSL) and a sharded key-value store (IronKV) correct, down to Dafny code. The liveness proofs are built by chaining intermediate progress conditions.
    • number: 1,400 specification, 5,114 implementation, 39,253 proof lines; 395 minutes to check
    • number: IronRSL liveness: 7,869 proof lines, 115 minutes; IronKV liveness: 2,093 lines, 23 minutes
    • number: about 3.7 person-years
    • number: implementation-level proof/code ratio 3.6
    • limits: The top-level spec, event loop, Dafny, runtime, OS and hardware are trusted. IronRSL liveness needs eventual timing bounds and a live quorum. The reduction argument is on paper.
    • how much was read: most of it read
    • source; notes: S8
    • record id: ironfleet-2015
  • Looney (2015)
    • title: Analysing Sanity of Requirements for Avionics Systems
    • what: Checks a set of temporal-logic requirements before any model exists: finds every smallest group of requirements that contradict each other, finds requirements implied by others, and suggests new requirements to cover behavior the set leaves open. Tested on random formulas, a plane-landing example, and four Honeywell avionics models.
    • number: Honeywell sets of 3, 5, 10 and 10 formulas: all consistent; two redundancies found; consistency took 0.1 s, 0.1 s, 73.6 s and 210879 s for the largest (pbit)
    • number: Landing example: R4 vs R6 and R1, R2, R5 were inconsistent; A5 and A6 were redundant; coverage rose 0% to 9.1%, 39.4%, 54.9% with 3 suggested formulas
    • number: Switching to the SPOT translator sped up checking by several orders of magnitude on larger sets
    • number: Honeywell engineers: tool-supported formalization took under 5 minutes per requirement after a week; requirement-elicitation stages took 18 per cent less time
    • limits: Needs requirements already written in LTL (Honeywell used a pattern tool, ForReq, from English). Largest industrial set was 10 formulas, which the authors call hardly a demonstration of industrial scale. Completeness needs a human to separate assumptions, required and forbidden behavior, and was not tested on Honeywell data. Honeywell requirements are confidential.
    • how much was read: most of it read
    • source; notes: Analysing Sanity of Requirements for Avionics Systems (2015)
    • record id: looney-2015
  • Verdi (2015)
    • title: Verdi: A Framework for Implementing and Formally Verifying Distributed Systems
    • what: Verdi proves an application correct under an easy network model. Then a verified system transformer changes the implementation so that it tolerates a harder fault model, and carries the property over. The proofs are in Coq.
    • number: Table 2 (spec / implementation / proof LOC): KV 41/138/337; primary-backup 20/134/1155; composition 5/N/A/19; Raft linearizability 170/520/4144
    • number: Table 2 lines spec/impl/proof: sequence numbering 20/89/576; KV 41/138/337; primary/backup 20/134/1,155; Raft linearizability 170/520/4,144
    • number: no comparable total person-time established in the review
    • limits: The network semantics and the TCB (the trusted computing base) are in Section 3. This paper is not the later complete Raft linearizability result.
    • how much was read: most of it read
    • source; notes: S29; notes: Choosing top-level distributed guarantees and trusted boundaries; notes: Appendix B: Concrete systems and theorem scope
    • record id: verdi-2015
  • AWS TLA+ report (2014)
    • title: Use of Formal Methods at Amazon Web Services
    • what: Engineers describe using TLA+ and the TLC model checker on ten AWS designs. TLC is a tool that tries every reachable state of a design to look for bugs. Before checking design changes, they wrote down the failure modes and the environment.
    • number: ten systems, seven teams; useful results after two to three weeks of learning
    • number: S3 networking 804 PlusCal lines, two bugs; DynamoDB replication 939 TLA+ lines, three bugs; EBS 102 PlusCal lines, three bugs
    • number: one DynamoDB bug needed a 35-step counterexample
    • number: Engineers learn TLA+ and get useful results in 2 to 3 weeks
    • limits: The method checks designs, not code, and does not prove anything about code. A lock-free structure still had a bug where something should eventually happen but never does. TLC missed it because the engineers did not check that kind of property.
    • how much was read: most of it read
    • source; notes: S13
    • record id: aws-tla-report-2014
  • Distributed Protocols and Heterogeneous Trust: Technical Report (2014)
    • what: # Distributed Protocols and Heterogeneous Trust: Technical Report (authored by agents unless marked 🧑) Sheff, van Renesse and Myers use information-flow labels to reason about distributed protocols whose participants disagree about which machines may crash or lie. The central guarantee is participant-specific: a failure that violates one participant’s assumptions must not damage participants whose assumptions still hold (§1.1, Q2). They generalize Bosco Fast Consensus and the OARcast/Nysiad construction. Evidence consists of mathematical/prose proofs, an offline SMT threshold search, and small consensus simulations. I read arXiv:1412.3136v1, stamped 9 December 2014 (Q1). The local PDF and the official v1 PDF retrieved on 19 October 2026 are byte-identical. Both have 2018/10/9 footers; those footers do not establish a new arXiv version or publication date. The report has 26 pages, six figures, Algorithm 1, Appendices A–B and 40 references, all read. There are no tables. ## Model and assumptions (authored by agents unless marked 🧑) The network is asynchronous and permits all participants to communicate. Resending is assumed to make delivery reliable unless sender or receiver fails. A faulty participant cannot forge a correct participant’s source identity; signatures are suggested (§2.1, Q3). Almost-sure termination adds the assumption that repeatedly sent concurrent messages eventually arrive in every possible order. Section 5 phrases this as random ordering. Appendix B.5 additionally needs a selection function with nonzero probability for each input value (Q36). These assumptions matter: ordinary asynchronous message delivery alone does not establish the termination result. A guru functions correctly and has true trust assumptions. A chump functions correctly but has false trust assumptions. The authors state that “chumps may receive ‘wrong’ results” (§2.2, Q4). Most guarantees concern gurus, rather than every participant that happens to execute correctly. The requirements also exclude some trust configurations: arbitrary mutual distrust is not automatically supportable (Q2). The labels adapt the Decentralized Label Model. Each integrity or availability policy names an owner and a principal trusted to influence content or availability. Principals may be machines, people or compound authorities. Conjunctive principals combine authority; disjunctive principals describe alternative authority. Label ordering and join/meet track how message combinations trade integrity against availability (§§3–4, Appendix A, Q5–Q8, Q32, Q41). “More restrictive” labels correspond to weaker usable assurances. The paper describes static reasoning before execution; it does not report a compiler enforcing these policies or a complete implementation proof. The simple synthesizers make the tradeoff concrete: accepting the first of three messages gives high availability but permits any sender to influence the value; requiring three identical messages increases integrity but makes each sender necessary. Contradiction can produce the detectable unavailable value none (§4.1, Q7, Q42). Survivor sets and failure-prone sets can be represented as labels separately for each principal’s crash and Byzantine expectations. For four participants tolerating any single failure, the system principal is the disjunction of the four triples, while the attacker principal is the disjunction of the six pairs (§4.2, Q8). ## Consensus construction and proofs (authored by agents unless marked 🧑) Algorithm 1 broadcasts a proposal, waits for a sufficiently available received set, and examines sets of identical messages. A high threshold D permits decision; a lower threshold C forces a value into the underlying consensus. Otherwise a selection function chooses from received values. The underlying protocol can recursively be another fast-consensus round. A deciding participant then broadcasts its decision once more so that the remaining participants can proceed consistently (§5, Q10–Q11). A deterministic selector may let an attacker prevent convergence, so randomness is advised (Q12). The stated properties have different scopes (§5, Q9): - Agreement: any two deciding gurus choose the same value, and repeated decisions by a guru agree - Unanimity: if all correct participants initially propose v, a deciding guru chooses v - Validity: if a participant decides and all participants are correct, some participant proposed the value - Progress: gurus eventually decide if the underlying consensus terminates - Termination: recursive fast consensus eventually decides for gurus with probability 1 under the extra random-network assumptions Validity is deliberately weak: it does not guarantee a nonfaulty participant proposed the value in an execution containing Byzantine faults. Probabilistic termination is not a bounded worst-case or expected-round theorem. For homogeneous assumptions, c is the total number permitted to be unavailable and b is the number permitted Byzantine, with c ≄ b. The received-set threshold is |R| ≄ n−c, decision requires |S| > (n+c)/2+b, and change requires |S| > (n−c)/2. The requirement is n > 3c+2b, reducing to n > 3c for crashes only and n > 5b when c=b. Tightness is attributed to earlier Bosco work, not newly proved here (§5.1, Q12). For heterogeneous assumptions, each participant supplies its own availability threshold and change/decision labels. Constraints (1)–(6) ensure that sender failures bound message availability, tolerated failures cannot block a sufficient set, progressing parties can continue without blocked parties, decision thresholds imply change, liar/wrong sets cannot redirect other votes, and one guru’s decision forces other correct parties to enter the underlying consensus with that value (§§5.2–5.3, Q13–Q18). This is an explicit set of conditions to satisfy, rather than a theorem for every label assignment. Appendix B proves agreement separately for decisions in the same round and different rounds. It uses constraints (4)–(6), unanimity/agreement of the underlying protocol, and continued participation by deciding parties. Unanimity propagates the common correct proposal through the underlying protocol. Fault-free validity follows from selecting received values and authentic message sources. Progress uses constraints (1)–(3) to ensure sufficient messages arrive (Q33–Q35). The termination argument deserves a precise limit. Appendix B.5 concludes: “in any pair of consecutive rounds, there is a non-zero probability a guru will decide. Therefore, each guru, with probability 1, eventually decides” (Q36). Nonzero probabilities that can decrease across rounds do not alone justify almost-sure termination. The appendix does not explicitly supply a uniform conditional lower bound, independence, or a complete stochastic fairness argument. Its intended strong network/selection assumptions may provide that missing step. This read flags a proof-detail dependency; it does not supply a counterexample to the protocol. Two notation concerns are visible in the PDF, not extraction artifacts. Equation (3) quantifies R ⊆ P but uses S in its body (p.12, Q16). Figure 3’s A_sys row for Bob/Carol/Dave/Eve prints an integrity-policy superscript I where the text describes an availability threshold (p.13, Q17). The record preserves both; it does not silently repair the formulas or claim a checked encoding. ## Five-party case and measured results (authored by agents unless marked 🧑) Alice tolerates arbitrary failure by Bob and no other failures. Bob, Carol, Dave and Eve tolerate Byzantine Alice plus at most one crash among themselves (§§1, 2.2, 5.4, Q19). The searched thresholds let these five reach consensus. A homogeneous envelope must allow one Byzantine failure and one additional crash, hence b=1, c=2 and n>8: nine participants (Q21). Five versus nine exploits different trust structure; it does not violate a lower bound for an identical failure model. Alice sometimes must listen to Bob despite distrusting him. If Bob is Byzantine, the others’ trust assumptions fail and Alice alone may remain a guru. But when Bob is merely crash-prone, Carol and Dave might change their votes after hearing Bob and Eve. Alice therefore waits for Bob or Eve to preserve agreement in executions where those other participants are gurus (§5.4, Q20). This illustrates why individually “ignoring everyone distrusted” is not sufficient. The authors simulated 1000 instances for homogeneous nine-party Bosco and the corresponding heterogeneous five-party protocol. Each round’s message ordering and the selector’s choice are uniform random. All parties begin with different values. They compute the mean probability of a participant deciding after each round and show standard-error bars (§5.4, Figs.4–5, Q21–Q23). Exact curve ordinates and error magnitudes are not tabulated. The captions say “in each round,” while the prose says “after each round” and the curves increase toward one; this record retains reported round quantiles without reconstructing the raw event distribution. The explicit reported outcomes are (§5.4, Q21, Q24): - no failures: heterogeneous median 3 rounds and 95th percentile 5; homogeneous median 5 and 95th percentile 8 - Alice Byzantine and Bob crashed: heterogeneous 95th percentile 4; homogeneous median 6 and 95th percentile 12 The heterogeneous median in the fault scenario is not explicitly stated in the prose, so none is invented. Byzantine Alice’s behavior is specific: she proposes a fresh never-before-seen value every round. This is a chosen attack, not comprehensive Byzantine exploration. The paper attributes the faster convergence partly to reduced contention among fewer active participants. It evaluates the whole customized configuration, without isolating label adaptation from the participant-count change. It reports no deployed throughput, wall-clock communication latency, hardware, random seed or raw per-run result file in the paper. For threshold synthesis, the requirements are encoded in quantifier-free bitvector logic and Z3 is used offline. Four- to six-party protocols reportedly take “a few minutes for each protocol” (§5.4, Q25). There are no exact timings, hardware or Z3 version. Checking given labels is described as polynomial, placing the search problem in NP; precise hardness remains future work. This is not a claim of NP-completeness or polynomial-time synthesis. Section 5.5 adds a distrusted client as a participant so the best case is client→servers→client, without waiting for inter-server communication. The construction is subject to threshold requirements and explicitly trades bandwidth for latency; there is no implementation timing experiment (Q26). ## OARcast, Nysiad and artifact evidence (authored by agents unless marked 🧑) OARcast has a designated sender and echoers. Messages carry author and relay signatures plus sequence numbers. Echoers rebroadcast unseen sender messages, cease on conflicting sender-signed values for a sequence number, and deliver only after lower sequence numbers and a sufficient identical-echo threshold. Constraint (7) prevents two gurus from delivering different values for the same position (§6.1, Q27–Q28). If the sender is correct, no correct participant (even a chump) can simulate a different ordering. Liveness further requires a correct sender and enough uncompromised echoers. The report says its correctness proof “proceeds exactly as in [13, 14]”; it does not give a separate full OARcast appendix proof (Q28–Q29). Nysiad simulates a crash-tolerant system of deterministic state machines. Each simulated machine gets an OARcast sender. A host accepts a simulated message only when its own simulation independently computes an identical message and the matching OARcast delivers it. Gurus thus simulate the same execution and ordering. A faulty designated sender can block availability without independently changing the derived message value/order; each host’s own integrity and availability still constrain its simulation (§6.2, Q30). Footnote 2 limits OARcast integrity to uniform guaranteed delivery and ordering; application content can have further constraints. A 3f+1 crash-Bosco conversion using a deterministic selection function is described as 3f+1 Byzantine consensus with best-case two sends, compared with Fast Byzantine Paxos “by this very simple metric” (Q30). Nysiad has no empirical evaluation here. The linked Dropbox ZIP was recovered successfully. It contains only pysmt/pylisp2.py (9444 bytes) and pysmt/pysmt.py (40332 bytes). Both were read in full, 1151 LF-delimited lines including terminal empty lines. They are a Lisp parser and Python-2-style SMT converter/solver wrapper. The converter eliminates supported finite datatypes and Boolean interfaces, turns functions into bitvector lookup tables, unrolls quantifiers, emits QF_BV headers, and defaults to invoking z3. It includes local threshold optimization and HTML analysis modes (Q37–Q40). Its help explicitly notes that compactly declared bitvector lengths can entail exponential file expansion (Q37). No README, protocol constraint input, simulator, dependency pin, historical commit identifier or experiment output is present in this particular archive. The source supports the existence of a QF_BV preparation and solver workflow, but cannot alone reproduce the five-party thresholds or plotted simulations. No author code was imported or executed; no solver, prover, verifier or compiler was run. Only reader extraction, rendering, hashing, arithmetic and validation scripts were used. Simulation and synthesis outcomes remain author-reported. ## Relevance to the requested topic (authored by agents unless marked 🧑) This paper adds a useful formal-specification question for distributed systems: whose assumptions must hold for each guarantee? Its concrete contributions are a label-based description of integrity/availability, explicit threshold constraints, conditional consensus proofs, and a worked heterogeneous deployment comparison. It separates agreement from delivery availability and shows how Byzantine behavior can deny progress without corrupting the eventual ordering. There is no Verus, verified Rust, TLA+ or LLM-agent experiment. Transfer to agents writing specifications/proofs is reader inference: state trust and scheduling assumptions per participant, retain the weak validity quantifier, check threshold side conditions, and distinguish prose proof, SMT synthesis, simulation and implementation verification. A useful evaluation would test multiple trust graphs and adversarial schedules while pinning constraint encodings and the simulator. Confidentiality, self-interested behavior and general automatic protocol transformation remain future work (§7, Q31). The quotation identifiers used above are defined in quotes.json and mirrored in the JSONL record; each definition includes its exact source span and section. Reading Figure 3’s vote combinations as distinct participants, its intended change threshold is two matching votes and its decision threshold three among Bob, Carol, Dave and Eve; Alice’s own vote does not contribute to those counts (Q17). This helps explain why she can need Bob’s message despite distrusting him.
    • limits: Asynchronous reliable source-authenticated messages and participant-specific constraints (1)–(6); guarantees mainly for gurus. Recursive almost-sure termination adds random/fair message ordering and full-support selection. Appendix B.5 leaves its stochastic justification terse. Validity applies only when all participants are correct. Nysiad assumes deterministic state machines. No mechanized full protocol or implementation proof is reported.
    • how much was read: most of it read
    • source
    • record id: distributed-protocols-and-heterogeneous-2014
  • Dialog Model Checking Fault-Tolerant Algorithms (2012)
    • title: Starting a Dialog between Model Checking and Fault-tolerant Distributed Algorithms?
    • what: Introduces a parameterized modeling framework for threshold-guarded fault-tolerant message-passing algorithms. Processes are extended control-flow automata with symbolic parameters, threshold guards, asynchronous interleavings, message buffers and faulty-process nondeterminism; instances become Kripke structures checked in LTL without next. The paper makes the formalization problem explicit (pseudocode semantics and hidden environmental assumptions), defines parameterized process skeletons and CFA operational semantics, and translates a family of broadcast algorithms under Byzantine, symmetric, omission and crash faults. Spin/Promela experiments systematically vary resilience and specifications: expected resilience boundaries are recovered, and impossible configurations produce violations.
    • number: Byzantine n>3t; symmetric/omission n>2t; clean crash n>t
    • number: valid cases Spin-verified; n=7,t=3 Byzantine relay specification violates as expected
    • number: n=5 omission with three faulty processes violates C and R
    • number: n=11 experiments exhaust memory
    • limits: Experiments are bounded finite instances and do not establish parameterized correctness; n=11 runs out of memory. The framework initially targets asynchronous threshold algorithms, with partial synchrony and round models left for future work. Correctness depends on explicit resilience, delay, fault and scheduling assumptions.
    • how much was read: most of it read
    • record id: dialog-model-checking-fault-tolerant-algorithms-2012
  • TLAPS (2012)
    • title: TLA+ Proof System (TLAPS) and its temporal support
    • what: # TLA+ Proofs (authored by agents unless marked 🧑) Denis Cousineau, Damien Doligez, Leslie Lamport, Stephan Merz, Daniel Ricketts and HernĂĄn Vanzetto, 2012. This record reads the 16-page extended article, arXiv:1208.5933v1, dated 29 August 2012. Its first-page footnote says a shorter version appears at FM 2012; reference [7] gives LNCS 7436, pp 147–154. The official TLAPS publications page links both a longer article and a Peterson model (Q1,Q3,Q30,Q37). The shorter proceedings paper was not separately read. The inventory’s cs.LO label is not the PDF’s classification: the PDF says cs.SE (Q1). The article explains how to write, decompose, check and maintain TLA+ proofs through Peterson’s two-process mutual exclusion algorithm. Its central result is an illustrated invariant proof, backed by reported TLC and theorem-prover checks. The most important qualification is explicit: the displayed final temporal QED is “proof omitted” (Figure 6, Q19), because the then-current TLAPS could not check temporal reasoning (Q11). The state-level proof obligations are reported checked; the complete temporal theorem is justified by standard induction rules in the explanation, rather than entirely checked by the presented tool. Liveness is outside the demonstrated verification. ## Reading and evidence scope Read all 16 PDF pages in text and rendered images, including sections 1–6, all six figures, every displayed formula/proof and all 24 bibliography entries on pp 14–16. There is no appendix, checklist, numbered equation, numerical plot or printed table. The six figures contain the PlusCal algorithm, its TLA+ translation, high-level proof, inductive invariant, preservation-proof outline and hierarchical proof. This is one mutual-exclusion theorem target shown at successive levels of detail, not six independently evaluated algorithms. The local inventory PDF and freshly fetched official arXiv PDF have identical bytes. Read the official TLAPS publications page and two complete plaintext Peterson modules from the official tlaplus/tlapm repository, pinned to commit 901ae51ed5224f88d43a1a02969cd9be4ed1b48d, dated 2026-10-16. One module is the publications-page artifact path; its bytes match the separately fetched live official model. The second is under doc/fm2012. These are retained example artifacts, not an audit of the current TLAPS implementation. The repository tree was inventoried to locate them. Other examples, proof-manager/backend implementation, modern tutorials, the shorter article and recursively cited case-study papers were not read. The modern repository pin does not establish the exact executable versions used in 2012. No author code, PlusCal translator, TLC, TLAPS, Isabelle, Zenon or SMT solver was executed or imported. No model, serialized dataset or checkpoint was loaded. The reader checks are symbolic reasoning, file comparisons and metadata/arithmetic checks. quotes.json contains exact passages with section/page, LF lines and character slices; figure-evidence.json preserves every figure listing. numeric_tables.json explicitly records zero tables and the limited quantitative claims. The extracted listings often render □ as 2 and a prime as 0; quotes retain those literal extraction bytes, while the analysis uses the symbols confirmed in the rendered PDF. source-scope.json, source-files.json and hashes.json document the reading boundary and bytes. ## Specification and assumptions TLA+ combines linear-time temporal logic, Zermelo–Fraenkel set theory with choice, and modules. The proof language adds hierarchical natural-deduction structure. The Toolbox is an Eclipse-based interface to both TLC model checking and TLAPS proof checking, so the same formulas can be tested and used in deductive proofs (Q2). These descriptions concern the paper’s 2012 tools; they are not a current feature inventory. The example has exactly two process identifiers, 0 and 1, with Not exchanging them. Shared variables are a Boolean-valued flag function, a turn value initially 0, and the generated program-counter function pc. Initially both flags are false and both counters are at a0. Each process repeatedly sets its flag, gives the other process the turn, checks the other’s flag and turn through two separate labeled tests, executes the critical-section skip, then clears its flag (Q5–Q8). Atomicity is specified by PlusCal labels: an action runs from one label to the next. Figure 2 exposes seven action formulas per process, and Next existentially selects one process’s action. Reads/writes and control changes have exactly the interleaving semantics of these formulas. The example supplies no weak-memory, compiler-reordering, machine-instruction, crash, recovery or network-message model. Correctness of a compiled Rust or C implementation would need a separate correspondence argument. The critical section itself is represented by an atomic skip; the paper’s property is that the two program counters never simultaneously equal cs (Q6–Q9). The full specification is Spec = Init ∧ □[Next]_vars, with vars collecting flag, turn and pc. Brackets admit either a Next transition or a step leaving all listed variables unchanged. A behavior is an infinite state sequence. Stuttering is included to simplify refinement, not to assert progress (Q7,Q8,Q10). There is no fairness clause in the displayed Spec. A reader witness repeats the initial state forever: Init holds, every step satisfies UNCHANGED vars, and neither process ever reaches cs. Thus that exact Spec does not imply eventual entry into a critical section. This is compatible with its mutual-exclusion safety property. The paper says liveness can be expressed and proved in TLA+, but does not give the extra progress assumptions or a liveness proof here (Q4; math-witness.json). It would be wrong to infer starvation freedom merely from the safety theorem. ## What is proved, and the checking boundary The target is Spec ⇒ □MutualExclusion. Its three state-level obligations are Init ⇒ Inv, Inv ∧ [Next]_vars ⇒ Invâ€Č, and Inv ⇒ MutualExclusion. Figure 3 and §3.1 explain how propositional reasoning plus temporal induction and monotonicity yield the temporal theorem from these premises. They then state: “TLAPS does not yet handle temporal reasoning, so we omit the proof of the qed step” (Q11). Figure 6 calls itself the “complete hierarchical proof” while visibly retaining that omission (Q19). This is a disclosed tool limitation, not evidence that the mutual-exclusion theorem is false. Inv is TypeOK ∧ I. TypeOK constrains pc to seven labels per process, turn to {0,1}, and flag to Boolean-valued functions on {0,1}. I says a process from a2 through a4 has its flag set. A process at cs or a4 excludes the other from both cs and a4; if the other is still in either waiting-test location, turn favors the process already in that region (Q12). The stronger control-state conditions explain why the simple target predicate is preserved even across the entry/exit protocol. Two small reader checks clarify the formula. Init satisfies TypeOK, while all control-state antecedents in I are false at a0. If pc[0]=cs, I for process 0 excludes pc[1]=cs; if pc[0]≠cs, MutualExclusion already holds. These checks cover initialization and implication to the target. They do not replace the preservation proof or independently certify the tool. TypeOK describes 7ÂČ×2×2ÂČ=392 possible valuations; that is a domain-size calculation, not the paper’s reported 58 reachable states (math-witness.json). The paper first reports TLC checking execution errors and MutualExclusion over all 58 reachable states of this particular finite model. It also checks inductiveness by replacing Init with Inv, model checking Inv ∧ □[Next]_vars. Starting from every state satisfying the candidate invariant tests preservation beyond the original reachable-state set. For more complicated or infinite-state specifications, the authors recommend small-instance model checking as a way to find errors, and explicitly limit its ability to establish general inductiveness (Q9,Q12). A successful finite instance is not a universal proof for arbitrary process counts or data domains. The illustrated checks also reveal the human work. A leaf proof citing only Init and Inv fails because TypeOK and I remain uninterpreted. Supplying their definitions lets TLAPS prove initialization. Expanding definitions for the entire preservation obligation still fails with the default provers and produces a 65-line obligation. CVC3 through the SMT backend proves it “in a few seconds” (Q13–Q15). No hardware, precise solver versions, timeout, repeat count or full timing log accompanies that statement. To demonstrate hierarchy rather than rely on this easy SMT success, the authors deliberately decompose the preservation proof using Zenon and Isabelle. The SUFFICES step replaces [Next]_vars with Next only after separately proving the unchanged-variable case. It then splits Invâ€Č into TypeOKâ€Č and Iâ€Č. Zenon proves the SUFFICES reduction; Zenon fails on the stated TypeOKâ€Č proof but Isabelle succeeds. Both fail on Iâ€Č without further decomposition (Q16–Q17). The next level introduces an arbitrary process j, names its invariant subexpression as I!(j), and picks the process i that performs the Next action. Instead of seven action-by-action cases, two cases, i=j and i≠j, suffice for the displayed example. Explicit facts and definition expansions then discharge the leaves. A case step’s own name denotes its case assumption, so citing that name within its proof is not circular citation of its conclusion. NEW-bound assumptions and the PICK membership fact are automatically available within scope; ordinary facts still need the stated context discipline (Q18–Q19). ## Proof management, reuse and trust The Proof Manager translates proof steps into sequents with a goal and context of symbols, assumptions and previously established facts. It tracks context changes and sends leaf obligations to backends. It records success, failure, cancellation and omission. The interface can check one step, theorem or file, show the exact failing obligation, navigate back to the producing proof, and hide irrelevant portions of the hierarchy (Q21–Q22). “Proof obligations are independent of one another” describes the ability to check conditional obligations in any order (Q21). It does not make a theorem valid while required assumptions or earlier steps remain unproved. The distinction matters in this very example: the state-level work can be developed independently while the final temporal QED is omitted. Global completion requires all needed obligations and the correct bridge to the stated property. Fingerprinting stores an obligation’s status under a canonical representation. Bound variables become de Bruijn indices, so renaming them does not change the representation; unused symbols and hypotheses are removed from the context. This supports reuse after proof reorganization, moving a step or removing and later reinserting it. Status can also be queried without launching proofs (Q23). The paper describes the mechanism but gives no hash-collision theorem, implementation-level soundness proof or controlled cache benchmark. Correct reuse depends on the representation preserving all relevant logical dependencies. This record did not inspect the fingerprint implementation. The backends described are Isabelle/TLA+, Zenon and SMT solvers. Default attempts use Zenon, then Isabelle; the SMT route translates obligations into SMT-LIB for CVC3, with native Yices/Z3 alternatives. Isabelle is the most trusted backend. Zenon can emit Isar proofs that Isabelle checks. The paper says certification of SMT proof traces is future work, so a successful SMT result should not be silently counted as Isabelle-certified evidence in this article (Q3,Q15,Q27). The trusted components also include translations and critical Proof Manager transformations such as distributing prime through addition. Users can disable fingerprints and reprove obligations, which addresses cache reuse concerns without removing the other trust dependencies. The authors further warn that an incorrect target formula can make a proof meaningless and that incorrect assumed mathematical facts can invalidate an apparent result. TLC can test those exact assumed formulas on instances; that supplies error-finding evidence, not a proof of every assumed mathematical statement (Q27–Q28). ## Evaluation and concrete larger cases The evaluation is a worked proof tutorial plus development experience, not a randomized user study or comparative prover benchmark. Its concrete local evidence comprises the 58-state TLC result, the failed/repaired leaf proofs, the 65-line preservation obligation, backend-specific outcomes and the qualitative CVC3 timing. There are no statistical estimates, repeated trials, task success rates, hardware budgets or uniform comparison across proof assistants (Q9,Q13–Q19). Larger uses are named: Byzantine Paxos, the Memoir security architecture, and Pastry lookup/join protocols. These are cited case studies, not complete proofs reproduced in this article (Q20). A cited 1100-line invariance proof has 100 non-leaf steps, illustrating the scale at which the hierarchy acts like nested lemmas (Q22). The claim that 100 conventional linear lemmas would be unreadable is the authors’ judgment, not a measured readability result. The strongest maintenance anecdote concerns Lamport’s Byzantine Paxos proof. He initially spent several weeks over several months on its safety proof while debugging TLAPS. Later he discovered the algorithm lacked the desired liveness property, changed it, repaired small bugs found by TLC, and re-established safety in a day and a half, about 12 hours of actual work. About three quarters of the new proof obligations had already been proved (Q24). This shows reported reuse during a real revision and separately shows why safety does not imply liveness. It does not report a newly checked liveness proof, an exact obligation count, or an isolated speedup attributable solely to fingerprinting. The related-work discussion compares declarative proofs and interface features with Mizar/Isar, reuse with KIV, set-theoretic/refinement approaches with Rodin/Event-B, and high-level specifications with VCC/Why source-code verification. These are architectural comparisons and historical author assessments, not present-day benchmark rankings (Q25). The conclusion also lists proof constructs not exercised in the Peterson example, including existential witnesses, local definitions and facts supplied implicitly to backends. Temporal reasoning and improved sequence support are planned work in the article (Q26,Q29). ## Static artifact findings Both pinned Peterson modules contain the full PlusCal comment, generated actions, candidate invariant, ISpec for inductiveness testing, and two variants of the same safety proof. One variant uses SMT for preservation; the other expands the hierarchy. Both end their top-level theorem with PROOF OMITTED (Q31–Q35). This independently preserves the article’s disclosed checking boundary in a usable example artifact. The source exists; no dynamic proof certificate or successful replay is supplied by this read. The artifact retains ProcSet and uses USE DEF ProcSet, matching the paper’s footnote about a definition inlined in Figure 2. MutualExclusion uses negated conjunction, logically equivalent to the paper’s disjunction. Source leaf proofs often cite Inv, Next and proc(i) directly where Figure 6 cites numbered steps; the explanatory text explicitly permits such fact references (Q7,Q17,Q32–Q35). The FM directory copy differs only by an unused NeverCS predicate and DEF versus DEFS spelling in one leaf proof (Q36 and retained file comparison). Neither difference establishes an algorithm change or runtime failure. The two files remain exact downloaded bytes. ## Contribution to the requested research topics This is directly relevant to formal verification of distributed systems and TLA+: it gives a concrete path from a labeled algorithm to a temporal specification, tested invariant, structured proof obligations, backend checks and maintained proof status. It makes both the specification assumptions and proof-completion boundary visible. Its larger-system anecdotes link those mechanisms to distributed protocols while leaving those cited proofs outside this article’s detailed evidence. It contains no Verus or verified-Rust development, LLM agent, generated-specification benchmark or automatic invariant-synthesis evaluation. Its transferable design ideas are therefore reader proposals: give proof agents explicit sequents and scoped context; use checker feedback to distinguish missing definitions from difficult obligations; split proofs without dropping stuttering or other cases; cache normalized obligations only with valid dependencies; and report omitted steps and certification routes alongside success counts. The article does not measure those proposals with LLMs. Its most useful evaluation lesson is to keep a correct formalization, state-level proof success, temporal completion, liveness, certificate checking and proof-reuse evidence separate.
    • number: Peterson mutual-exclusion example; proof obligations are split among back-end provers
    • limits: Exactly two processes and labeled atomic shared-state interleavings with arbitrary stuttering; no fairness/weakmemory/compiledimplementation correspondence. Reported state-level proof checks leave temporalQED explicitly omitted in2012tools. No liveness proof or fullTLAPSsoundness proof. Larger case studies cited; maintenance/timing evidence is anecdotal.2026modulepin does not identify2012executables.
    • how much was read: most of it read
    • source; notes: T01. Current TLAPS support: distinguish temporal reasoning from automa
    • record id: tlaps-2012
  • Effectively Nonblocking Consensus Procedures Can Execute Forever - a Constructive Version of FLP (2011)
    • what: # Effectively Nonblocking Consensus Procedures Can Execute Forever: whole paper reading (authored by agents unless marked 🧑) Robert L. Constable’s Effectively Nonblocking Consensus Procedures Can Execute Forever – a Constructive Version of FLP is arXiv:1109.3370v1,15 September 2011. Its frontmatter also gives July 17, 2008, a footnote describing changes through August 2011, and a May 20, 2021 print date. These identify the saved version rather than three independent research results. All 17 pages were read: Sections 1–2, their eight subsections, all lemma/theorem/corollary statements and proofs, Figures 1–7, the One Step Program, acknowledgments and ten references. All five contact sheets and individual4,10,14,16 were inspected. Original, local and official PDFs match. No author code, scientific-result artifact or formal checking tool was executed or loaded. [Evidence: Q0, frontmatter/abstract/dates, PDF pp.1–1; literal spans in quotes.json.] The contribution is a constructive variant of the Fischer–Lynch–Paterson impossibility argument. Instead of only proving that some indecisive run exists, the paper assumes a computable nonblocking witness and explains how to calculate every finite prefix of an infinite indecisive execution. Its distinction is between an existence proof and an effective construction, not a new consensus protocol. Classical nonblocking alone is handled using excluded middle/choice; the stronger effective premise supplies the computational content. Historical claims that earlier proofs lack this construction are Constable’s assessment of the cited work, not a literature-wide priority finding established here. [Evidence: Q1, §1.1, constructive versus classical problem, PDF pp.2–2; Q6, §1.4, full theorem/lemma/corollary summary, PDF pp.5–6; Q12, §2.2, full constructive/classical corollaries, PDF pp.10–11; literal spans in quotes.json.] The model is deterministic binary consensus with crash failures, reliable FIFO message channels and unbounded asynchronous delay. Processes have private state and messages in queues; executions are serialized into individual actions. Fairness requires every message to a nonfailed process eventually be read and every enabled action at such a process eventually be taken. Uniform inputs require the corresponding decision, and all deciding processes agree. The main construction concerns tolerating one failure, although no process actually crashes in its resulting fair run. Randomized termination, known-delay synchrony and Byzantine fault behavior are outside the stated theorem. [Evidence: Q3, §1.2, complete computing/fairness model, PDF pp.3–4; Q4, §1.3, consensus/nonblocking/witness, PDF pp.4–4; Q11, §2.2, CFLP theorem/full proof, PDF pp.10–10; Q12, §2.2, full constructive/classical corollaries, PDF pp.10–11; literal spans in quotes.json.] Constable defines the premise in §1.3: “P is called effectively nonblocking if from any reachable global state s of an execution of P and any subset Q of n − t nonfailed processes, we can find an execution α from s using Q and a process Pα in Q which decides a value v Ç« B.” Effective nonblocking is a total computable function wt(s, Q): for every reachable state s and every chosen set Q of n−t nonfailed processes, it returns a finite execution using Q, its deciding state and a process deciding a bit. This is an existential progress witness, not a promise that every continuation progresses. It is stronger information than an abstract claim that some extension exists. A constructive proof of nonblocking can supply such a witness; the paper cites Nuprl/Coq’s constructive setting and Mark Bickford’s nonblocking formalizations as motivation. It does not present a checked Nuprl or Coq development of this complete CFLP proof. [Evidence: Q4, §1.3, consensus/nonblocking/witness, PDF pp.4–4; Q2, §1.1, Nuprl/Coq and blocking motivation, PDF pp.3–3; literal spans in quotes.json.] The paper’s v-possible predicate asks whether one of finitely many wt(s, Q) results decides v. For one-failure tolerance this can be decided by n witness evaluations, one for each Q_i excluding P_i. That does not decide all possible future decisions. Effective bivalence instead includes explicit finite executions deciding 0 and 1; arbitrary bivalence remains undecidable according to the source. In particular, a witness may choose only 0-valued continuations even when another execution decides 1, so failure to find a 1 in those n selected witnesses does not establish univalence. The construction retains a known opposite-valued path rather than replacing that information by a finite sample of witness answers. [Evidence: Q5, §1.3, v-possible/effective bivalence, PDF pp.5–5; Q8, §2.1, finite witness-decision test, PDF pp.6–6; Q11, §2.2, CFLP theorem/full proof, PDF pp.10–10; Q13, §2.3, initialization/replay and witness independence, PDF pp.11–12; literal spans in quotes.json.] Initialization starts at all-zero inputs and flips one process at a time until all-one inputs. It chooses the first initialization s_k for which some witness decides 1. At s_(k−1), the witness excluding P_k decides 0. Replay that finite execution from s_k: only P_k’s initial state changed and it takes no step, so the other processes still decide0. Together with the 1-witness this constructs a bivalent initial state. With three processes the chain is 000→100→110→111; the first transition revealing 1 supplies the distinguished excluded process. This is ordinary explanatory substitution, not an executed trace. The witness itself need not return identical paths on the two inputs; the proof explicitly uses replay rather than assuming witness extensionality in unseen state. [Evidence: Q9, §2.1, full initialization proof, PDF pp.7–7; Q13, §2.3, initialization/replay and witness independence, PDF pp.11–12; literal spans in quotes.json.] The One Step Lemma takes explicit bivalent paths and a process P_i, and constructs a reachable state bâ€Č with two opposite-valued deciding paths using only Q_i. Its first proof walks backward along a finite 1-path, queries wt at predecessor states and uses agreement to transfer decisions across an isolated P_i action. The commutativity lemma permits executions of disjoint process sets to be replayed in either order while delaying cross-set messages. This depends on the asynchronous message model and on the selected actions remaining executable; it is not a general claim that arbitrary shared-memory operations commute. Figures 1–4 show the two decision branches and commuting diagrams. [Evidence: Q10, §2.1, full One Step proof/Figures 1–4, PDF pp.7–10; Q14, §2.3, both commutativity lemmata/proofs, PDF pp.12–12; literal spans in quotes.json.] David Guaspari’s alternative proof counts P_i actions on one branch of a fork. A fork is a pair of finite paths ending in different decisions; an i-fork has one branch avoiding P_i, and a full i-fork has both branches avoiding it. At the last P_i action, query the witness on Q_i. If its decision matches the branch already avoiding P_i, commutation produces a full i-fork after that action. If it matches the other branch, replace the suffix by the witness path and strictly decrease the number of P_i actions. Finite descent yields the One Step Lemma. The returned path length and witness-running time are unbounded by this paper; the finite descent measures distinguished-process actions, not total execution cost. [Evidence: Q15, §2.3, fork definitions/modification lemma, PDF pp.13–14; Q16, §2.3, alternative One Step proof, PDF pp.15–15; literal spans in quotes.json.] CFLP then cycles through processes and selected enabled actions. Before executing P_i’s action, it obtains a state bâ€Č bivalent via Q_i; replaying the two Q_i decision paths after that action preserves bivalence by commutativity and agreement. If the action was already executed while reaching bâ€Č, it is not repeated. Repeating this procedure supplies longer indecisive prefixes while giving each process turns. The source asserts the resulting execution is fair and failure-free. A formal extraction should explicitly enumerate pending messages/enabled actions so process-level round robin also discharges its stronger message/action fairness definition. The printed proof does not give that queue-selection policy or an explicit total function for the n-th output action. This is an extraction/detail obligation, not a counterexample to classical FLP. [Evidence: Q11, §2.2, CFLP theorem/full proof, PDF pp.10–10; Q3, §1.2, complete computing/fairness model, PDF pp.3–4; Q12, §2.2, full constructive/classical corollaries, PDF pp.10–11; literal spans in quotes.json.] The source separates three consequences. A purported deterministic single-failure terminating consensus algorithm supplies the needed nonblocking witness and contradicts the constructed run; §2.2 calls this FLP corollary constructive because its result is a contradiction. Strong FLP instead assumes nonblocking without a computable witness and invokes choice/excluded middle to obtain an infinite run. The Blocking corollary states that a procedure terminating on all failure-free executions must have a reachable state where one process’s failure prevents any decision. That last existence result is explicitly classical; it does not give an automatic algorithm locating the blocking state. Nontermination and a blocked state are different: the constructed run retains deciding continuations throughout. [Evidence: Q12, §2.2, full constructive/classical corollaries, PDF pp.10–11; Q2, §1.1, Nuprl/Coq and blocking motivation, PDF pp.3–3; literal spans in quotes.json.] Printed details need correction before turning this presentation into executable or checked code. The summary’s CFLP statement requires more than two processes, whereas its initialization lemma and FLP corollary use two or more, and the main theorem omits a count restriction; the record preserves that statement mismatch instead of claiming the displayed CFLP statement alone proves the two-process case. The fork proof’s final inequality prints i−len(φâ€Č)<i−len(φâ€Č), a false self-comparison; its preceding lemma correctly compares the new fork with the old one. Figure 7’s One Step Program is informal pseudocode with inconsistent s/S and path/process notation and unstated initialization details. It describes computational content, not a ready-to-run verified adversarial scheduler. [Evidence: Q6, §1.4, full theorem/lemma/corollary summary, PDF pp.5–6; Q11, §2.2, CFLP theorem/full proof, PDF pp.10–10; Q15, §2.3, fork definitions/modification lemma, PDF pp.13–14; Q16, §2.3, alternative One Step proof, PDF pp.15–15; Q17, §2.3/Figure 7, full program/conditions/invariants, PDF pp.15–16; literal spans in quotes.json.] The abstract’s “undefeatable attacker” is an in-principle consequence under the theorem’s premises. The construction needs access to the relevant global state, a correct total witness and control of an asynchronous schedule with arbitrarily long finite delays. The paper reports no network deployment, attack implementation, performance measurement, experimental protocol instance or complexity bound for this suggestion. It does not establish a practical denial-of-service method for protocols whose liveness depends on eventual synchrony or randomness. The full proof is a written mathematical proof; related Nuprl nonblocking work is reported but no complete CFLP proof artifact is provided or audited here. [Evidence: Q0, frontmatter/abstract/dates, PDF pp.1–1; Q2, §1.1, Nuprl/Coq and blocking motivation, PDF pp.3–3; Q11, §2.2, CFLP theorem/full proof, PDF pp.10–10; Q17, §2.3/Figure 7, full program/conditions/invariants, PDF pp.15–16; literal spans in quotes.json.] For this database the paper makes progress assumptions explicit and turns a proof witness into a scheduler construction. Reader follow-ups are a TLA+ statement separating fairness, eventual decision and mere existence of deciding extensions; a constructive Coq/Nuprl realization of the witness and finite-descent transformation; Verus/Rust proofs of finite path replay, FIFO state updates and witness-interface contracts; and LLM proof-agent tests that distinguish selected-witness decidability from bivalence, constructive output from classical existence, and unbounded computation from a measured attack. No Verus, verified Rust, TLA+ model or LLM evaluation is reported in this source. [Evidence: Q4, §1.3, consensus/nonblocking/witness, PDF pp.4–4; Q5, §1.3, v-possible/effective bivalence, PDF pp.5–5; Q11, §2.2, CFLP theorem/full proof, PDF pp.10–10; Q16, §2.3, alternative One Step proof, PDF pp.15–15; Q12, §2.2, full constructive/classical corollaries, PDF pp.10–11; literal spans in quotes.json.]
    • limits: Deterministic Boolean consensus; reliable FIFO asynchronous message passing; one-crash tolerance; total computable progress witness for each reachable state and permitted surviving subset; explicit finite opposite-decision paths. The construction assumes global-state and scheduling access. Fair action/message enumeration and productivity require explicit extraction details; printed process-count and pseudocode discrepancies remain qualified.
    • how much was read: most of it read
    • source
    • record id: effectively-nonblocking-consensus-procedures-2011
  • AOGG distributed graph systems (2010)
    • title: Modeling and Reasoning over Distributed Systems using Aspect-Oriented Graph Grammars
    • what: Defines aspect-oriented graph grammars (AOGGs) for modular system-wide policies over graph-rewriting distributed systems, gives an encoding into a single typed graph grammar, and uses AGG critical-pair analysis to detect conflicts and dependencies in aspect weaving. The base model uses DPO graph rules for a client-server system; aspects are rule-level spans with pointcuts, interfaces and effects. Log and security aspects respectively add execution tracing and read/write permissions. Weaving is non-reentrant and ordered, yielding a concrete graph grammar. Encoding operations R1–R3 represent rule spans as typed nodes/edges, and S1–S3 encode concrete rules/advices; the resulting typed graph lets AGG analyze both execution and weaving. In the case study, ExecuteSET/ExecuteGET conflict on shared data, while log/security advices are conflict-free, implying aspect-order confluence for that model.
    • number: four node kinds in base type graph
    • number: two aspects in encoded example
    • number: R1–R3 and S1–S3 encoding stages
    • number: one ExecuteSET/ExecuteGET conflict pair reported
    • limits: The semantics uses nondeterministic rule/match choice and DPO/SPO graph-transformation conditions; aspect order may matter when advices conflict. The encoding’s behavioral relation to the original base system plus aspects is identified as future work. Results are a small illustrative client-server grammar, not a quantitative distributed-system benchmark or proof of general confluence.
    • how much was read: most of it read
    • record id: aogg-distributed-graph-systems-2010
  • Verifying Safety Properties With the TLA+ Proof System (2010)
    • what: FirstpublicTLAPSrelease:hierarchical safety-proof management,backendtranslation/trust and Peterson/Bakery/incompletePaxoscases. # Verifying Safety Properties With the TLA+ Proof System (authored by agents unless marked 🧑) Kaustuv Chaudhuri, Damien Doligez, Leslie Lamport, and Stephan Merz, IJCAR 2010, LNCS 6173, pp142–148; arXiv:1011.2560v1, 11 November 2010. The venue/pages are confirmed by Stephan Merz’s author bibliography: “booktitle = {5th Intl. Joint Conf. Automated Reasoning (IJCAR 2010)}” and “{142-148}” (Q17; complete bibliography block in quotes.json). Read all seven PDF pages, §§1–5.1, acknowledgements and all 15 references; all seven page renders were inspected individually. The paper has no figures, tables, numbered theorems, benchmark suite, or appendix. This is the saved outside-index arxiv_all PDF, whose hash matches the reconstructed 352-path inventory. No author implementation or proof files were executed/imported, and no checkpoint or serialized data was loaded. Consultation and independent review are complete; the IJCAR bibliographic correction was applied. REVIEW.md records scope and root-only checks. The fetched author-hosted PDF has the same extracted body after removing the arXiv margin and declared glyph/spacing differences; author-copy-comparison.json records the comparison. No additional scientific content was inferred from that normalization. The paper describes the first public TLAPS release, its proof-obligation processing, and three example developments. It directly concerns TLA+ verification of concurrent and distributed systems. Its reported support covers invariance and step simulation but excludes liveness proofs. TLA+ the language can specify liveness; this release’s prover cannot establish those properties. These are historical 2010 capabilities, not a statement about today’s TLAPS. The authors state: “It handles almost all the non-temporal part of TLA+ as well as the temporal reasoning needed to prove standard safety properties, in particular invariance and step simulation, but not liveness properties” (§1 p1, Q1). ## Proof representation and what must be trusted Specifications and proofs share the TLA+ language. A hierarchical proof decomposes a theorem into steps and ultimately leaf obligations, each citing facts and definitions. TLAPM flattens imported/instantiated modules and sends processed leaves to backends. A user can work with incomplete proofs and choose which steps to check; the release uses pragmas to exclude proofs from checking. Thus a successful check of selected leaves does not itself establish completion of every claimed theorem. This completion check is a practical evaluation requirement inferred from the workflow. Q2–Q4 preserve the architecture and selection semantics. The backend called Isabelle/TLA+ implements the constant fragment as a dedicated Isabelle object logic. The paper explains that embedding into existing HOL/ZF logics was inconvenient because TLA+ is untyped, with no proposition/term distinction. Its single value type, classical first-order logic, equality, conditionals, Hilbert choice, Zermelo–FrĂ€nkel set axioms, and primitive function objects supply the mathematical basis. Natural numbers are introduced using a Peano structure whose existence follows from ZF; arithmetic is developed recursively. Tuples/sequences and records are functions, strings are character sequences. Ordinary “typing” facts become proof hypotheses: the paper’s n+0=n example needs a numeric n. Boolean conjunction is described as Boolean-valued even on arbitrary arguments. These are semantics/proof-library facts reported by the authors, not a reader audit of the object logic. Q9/Q10 give the details. Zenon searches for first-order proofs and emits Isabelle/Isar scripts checked against Isabelle/TLA+. The paper explicitly says “Zenon is therefore not part of the trusted code base of TLAPS” (§4.2 p5, Q11). That exclusion applies to this certificate-checking route; it does not make the entire TLAPS pipeline untrusted. TLAPM’s priming rewrite engine is expressly trusted. The generic SMT-LIB backend and Cooper Presburger arithmetic backend are expressly non-certifying in this release. “Certifying veriT” is a planned integration even though veriT is already among solvers tried through the generic non-certifying interface. Distinguishing solver brand from integration mode prevents a false claim that all SMT results were certified. Q3/Q5/Q11/Q12 preserve these boundaries. Backends reason over constant expressions. TLAPM moves primes through ordinary mathematical operators and leaves constants unchanged: (u=v+2c)’ becomes u’=v’+2c when u,v are state variables and c is constant. Double priming is rejected by the syntactic analyzer. Defined operators are hidden by default and expand when made usable. Modal operators may fail substitution of equals: knowing u=42 now does not imply u’=42. Reader illustration: a transition from u=42 to u’=43 satisfies the former but violates the latter. Usable non-substitutive definitions are expanded; hidden applications become opaque hashes, conservatively losing some valid equivalences such as O(e∧f)=O(f∧e). This is a stated completeness tradeoff, not a collision/security guarantee or a proof of implementation soundness. Q5/Q6 give the transformation and example. Positional and labelled references resolve subexpressions before later processing. In O(x,y)=x=20y+2, O(3,4)!2!1 selects 20·4. A label l on y·20 can keep referring to that term after unrelated surrounding syntax changes. The feature supports concise proof reuse, but the paper supplies no maintenance experiment. Default discharge tries Zenon, then Isabelle automation; pragmas can request tactics or other backends, often indirectly via a named standard theorem such as SimpleArithmetic. Q7/Q8 give these cases. The generic arithmetic route rewrites obligations into SMT-LIB AUFLIRA, often dropping assumptions outside that theory, with conservative sort detection for bound variables. Reader inference: proving a conclusion from fewer assumptions is logically stronger, so omission alone is not a soundness defect; translation and sort handling must still preserve meanings. The paper reports successful use of Yices, CVC3, Z3, veriT, and Alt-Ergo, without solver-specific counts, timings or comparative accuracy. It does not prove the soundness/completeness of these translations in this note. Q12 records the exact scope. ## Development practice and concrete evidence The authors first check finite instances with TLC and then attempt proofs. On leaf failure, TLAPM prints usable hypotheses and the goal, expanding usable definitions. Their reported common failure is omission of a needed fact/definition. They split difficult obligations into lower-level assertions, verify the local qed, then prove those assertions in any order. The example case split proves (P1∹
∹Pn)⇒Q by each Pi⇒Q. This is a concrete incremental authoring/debugging workflow, not evidence that partial obligations are sufficient. The Toolbox then only hid proof portions; broader integration was future work, while an Emacs mode provided hierarchical viewing and proof selection. Q13/Q14 preserve this historical distinction. The authors warn that unchecked “obviously true” assumptions can be wrong and recommend checking such data-structure facts with TLC. Finite model checking can expose counterexamples; it does not universally prove an unbounded assumption. That latter qualification is a reader inference, not a claim that the authors measured assumption-error rates. The claim that specification errors are likelier than TLAPS soundness bugs is also the authors’ engineering judgment, with no quantified comparison in this paper. Q3/Q14 carry both source statements. Section 5.1 gives these author-reported developments, without the actual full proof scripts: - two-process Peterson mutual exclusion: about 12 PlusCal lines and a proof of about 130 lines - N-process Bakery with atomic reads/writes: an 800-line proof - high-level Paxos: 100 TLA+ specification lines covering a consensus abstraction and two refinements; first refinement completed with a 550-line proof, second mostly proved and estimated to exceed 1,000 lines The Paxos case is explicitly incomplete, including the acknowledgement to Jean-Baptiste Tristan. The estimated second-proof length is not a measured completed artifact. Neither case length establishes checking time, human time, bug counts, proof coverage across implementations, liveness, or executable-code correctness. The N-process claim concerns the mathematical example as reported, not a finite-N experiment independently rerun here. Q15/Q16 preserve the complete cases. The library is reported to contain more than 1,400 lemmas/theorems, about 200 pages of pretty-printed Isar. These size measures and the three case descriptions support feasibility of the release; no theorem about the verifier itself, controlled user study, performance comparison, memory result, automated success rate or systematic experiment is supplied. The full development files and checker outputs were not inspected/reproduced in this reading. “It has not turned out to be difficult once the proof idea has been understood” is an author experience report, rather than a measured proof-automation guarantee (§5.1 p7, Q16). For the database, this is direct foundational evidence for high-level safety proofs and TLA+ proof tooling. It contributes explicit trust distinctions, partial-proof management, priming/substitution pitfalls, finite-model-checking practice, and a deliberately incomplete Paxos case. It has no Verus, verified Rust, or LLM experiment. A proposed use as an evaluation reference for proof agents is reader inference: record the precise theorem and unchecked assumptions, require every obligation, distinguish certificate-checked from trusted solver routes, and report whether the intended specification captures the requirement.
    • limits: Historical2010safetyfragment;Isabelleobjectlogic,TLAPMtrustedrewrites and noncertifyingarithmeticpaths. Selected/incompleteproofspossible;uncheckedassumptionsandspecificationvalidityremainhumanresponsibilities. Fullproofscripts/checkerresultsnotread/rerun;noquantitativetime/memory/successbenchmark.
    • how much was read: most of it read
    • source
    • record id: verifying-safety-properties-with-2010
  • Teaching Concurrency (2009)
    • what: It argues that invariance, meaning a fact that holds in every state, is the key to understanding concurrent systems. It also argues that the spec matters more than the algorithm.
    • how much was read: most of it read
    • record id: teaching-concurrency-2009
  • Woodcock survey (2009)
    • title: Formal Methods: Practice and Experience
    • what: Survey of industrial formal-methods practice combining a new questionnaire covering 62 projects, earlier surveys, eight highlighted industrial project families, and proposals for reusable verification experiments in the Verified Software Repository. Explains formal methods across requirements, specification, architecture, design, implementation, testing and maintenance. The new survey collected structured questionnaires November 2007–December 2008; 56 project reports came from involved individuals and six from literature. Reports application areas, size bands, techniques, expertise/training, perceived time/cost/quality effects and intentions to reuse. Compares model-checking uptake across decades using Fisher exact tests. Eight highlighted families cover Transputer floating-point microcode, railway control, Mondex, AAMP processors, Airbus SCADE, the Maeslant barrier, Tokeneer and Mobile FeliCa. They expose learning/reuse costs, translation and optimization bugs outside proof boundaries, requirements clarification, selective formalization, and tool limitations. Discussion favors choosing rigor by component/property, robust supported tools, familiar design-language interfaces, and integration with existing development processes. Repository proposal requires explicit proof assumptions and limits and reusable theory/artifacts; pilots include file stores, FreeRTOS, auctions, pacemakers and hypervisors alongside Mondex/Tokeneer.
    • number: Model checking in surveyed projects: 13% in the 1990s versus 51% in the 2000s; two-tailed Fisher p=0.003.
    • number: Survey: 62 projects; 56 participant reports and six literature reports; about half supplied code size.
    • number: Figure 6 quality improvement: 92% of cases reported an increase, none a decrease; this is a perception measure.
    • number: Tokeneer: 9,939 core Ada lines plus 16,564 SPARK annotation/comment lines; 260 reported person-days, excluding independent testing contribution.
    • limits: Historical 2009 synthesis, not a current adoption census or controlled causal evaluation. Open-invitation sampling favors the authors’ contacts, includes few model-checking contributions and underrepresents disappointed stakeholders; Europe dominates. Outcomes mostly report participant beliefs, with no comparison population or reliable universal cost model. Most projects lack relative time/cost evidence; reported quality improvement is not a measured 92% defect reduction. Significance tests concern this selected sample and do not remove selection/confounding bias. Industrial project claims summarize cited reports and were not independently reproduced. Some formal work covers models, selected code, selected properties, or parts of certification rather than a complete implemented system. Tokeneer’s tabulated 4% system-testing effort excludes independent SPRE testing; the text estimates 25% as more representative. The new survey’s individual responses and underlying dataset were not inspected. Recovered STFC author copy is 40 substantive pages with placeholder journal metadata, versus DOI/Crossref 36 pages; repository record explicitly links this title/file to DOI 10.1145/1592434.1592436, whose short metadata title is Formal methods. Database keyword/researcher estimates are explicitly rough historical estimates, not reliable counts of the field.
    • how much was read: most of it read
    • source; notes: S28
    • record id: woodcock-survey-2009
  • TLA+ chapter in Software Specification Methods: An Overview Using a Case Study (2006)
  • PROPEL (2002)
    • title: PROPEL: An Approach Supporting Property Elucidation
    • what: Presents property patterns both as disciplined natural language and as finite-state automata. It shows the person writing the property the alternative meanings (repeats, response, scope boundaries).
    • limits: The notes read the author’s technical report, not the typeset proceedings.
    • how much was read: most of it read
    • source; notes: Requirements methods predating LLMs
    • record id: propel-2002
  • Goal-Oriented Requirements Engineering: A Guided Tour (2001)
    • what: The paper breaks goals into smaller obligations assigned to software or environment actors. Obstacles and conflicts help find missing requirements. A spec is complete with respect to a set of goals when the goals follow from the spec plus domain properties.
    • how much was read: most of it read
    • source; notes: Requirements methods predating LLMs
    • record id: goal-oriented-requirements-engineering-2001
  • Property Specification Patterns (1998)
    • title: Property Specification Patterns for Finite-State Verification
    • what: The paper gives reusable patterns and scopes for properties, such as absence, response and precedence. It maps them to formal languages.
    • limits: A pattern cannot tell the agent which guarantee the human left out. Users must still know enough to express the requirement.
    • how much was read: most of it read
    • source; notes: Requirements methods predating LLMs; notes: papers
    • record id: property-specification-patterns-1998
  • Four Dark Corners of Requirements Engineering (1997)
    • what: The paper separates three things: facts about the environment that are wanted, facts about it that are assumed, and behavior the machine can enforce at its interface. The spec plus domain knowledge must imply the requirements.
    • how much was read: most of it read
    • source; notes: Requirements methods predating LLMs
    • record id: four-dark-corners-of-1997
  • Formal Methods: State of the Art and Future Directions (1996)
    • what: Surveys formal specification, finite-state model checking and machine-assisted theorem proving, using industrial case reports to explain their benefits and limits. It then proposes research, tool, education and transfer priorities. Formal methods alone do not guarantee correctness [Q1]. Contrasts rich sequential specification languages (Z, VDM, Larch) with concurrent notations; explains exhaustive checking and counterexamples versus proof by axioms and inference [Q4,Q7]. Discusses composition, decomposition, abstraction, reuse, hybrid systems and integration of methods. Tool criteria include early benefits, incremental gains, reuse, integration, ease of use and focused analysis [Q8–Q10]. Industrial examples include CICS, CDIS, C130J, TCAS II, SCI, NewCoRe/ISDN, HDLC, arithmetic circuits, processor instructions and microcode.
    • number: CICS: estimated 9% development-cost reduction [Q2]
    • number: CDIS: about 0.75 faults per thousand lines, described as two to ten times better than selected comparison projects [Q3]
    • number: NewCoRe: 145 requirements, about 7,500 SDL lines, 112 errors; approximately 55% inconsistent requirements [Q6]
    • limits: A 1996 survey and research agenda, not a new controlled comparative experiment. Industrial costs, fault rates and successes are cited case reports; they do not establish a general causal effect. Model checking faces state explosion [Q5]; theorem proving can cover infinite domains but may require substantial human guidance. Tool strengths and modeling assumptions must be stated [Q9]. No modern Verus, TLA+ or LLM evaluation.
    • how much was read: most of it read
    • source
    • record id: formal-methods-state-of-1996
  • The Semantics of TLA on the PVS Theorem Prover (1996)
    • what: Defines Lamport’s Temporal Logic of Actions (TLA, a logic where a system is a set of allowed state changes and properties are ‘always’ and ‘eventually’ statements) inside the PVS proof assistant. The hard part is hiding a variable (the existential quantifier over program variables), which needs a choice operator.
    • number: 17 pages
    • number: one worked example: two counters x, y with weak fairness on both increment actions
    • limits: Definitions only. It proves one lemma (stut equals the stuttering-removal function, Theorem 1) and gives no verified system, proof rules, or tooling. Report is marked unpublished and not peer reviewed.
    • how much was read: most of it read
    • source; notes: ## The semantics of TLA on the PVS theorem prover (1996)
    • record id: the-semantics-of-tla-1996
  • Linearizability (1990)
    • title: Linearizability: A Correctness Condition for Concurrent Objects
    • what: Defines linearizability: each operation takes effect at a single instant between its call and its reply, and the history must match some allowed sequential history.
    • limits: By itself it does not promise that requests finish, that data survives crashes, or that two retries count as one operation. That is the notes’ inference.
    • how much was read: most of it read
    • source; notes: Choosing top-level distributed guarantees and trusted boundaries; notes: S4
    • record id: linearizability-1990
  • End-To-End Arguments in System Design (1984)
  • Bus Protocols: MSC-Based Specifications and Translation into Program of Verification Tool for Formal Verification
    • what: Develops a workflow translating Message Sequence Chart bus-protocol specifications into SMV verification programs, with syntax/semantic analysis intended to detect deadlocks and protocol inconsistencies before implementation.
    • number: Formal verification uses the SMV model checker
    • number: No substantial runtime or benchmark suite reported
    • limits: The approach relies on MSC expressiveness and a translation preserving the modeled protocol; verification is bounded by the generated SMV model and selected bus scenarios. The report presents methodology and examples rather than broad quantitative benchmarking.
    • how much was read: most of it read
    • record id: bus-protocols-msc-based
  • Liveness Manifestos
    • title: Liveness Manifestos (NYU ACSys ‘Beyond Safety’ workshop page)
    • what: Workshop participants state whether proving liveness is worth it. Lamport lists four problems. McMillan, Vardi, Boigelot and Sistla add views on when liveness helps, and when bounded safety can replace it.
    • limits: This is not a paper. The workshop year is not stated.
    • how much was read: most of it read
    • source
    • record id: liveness-manifestos
  • VerusSync docs
    • title: VerusSync state-machine documentation
    • what: The Verus state-machine documentation explains VerusSync token generation for shared state and gives a counting example with transition proofs.
    • limits: Documentation page, not an independent artifact evaluation.
    • how much was read: most of it read
    • source
    • record id: verussync-docs
  • Closing the verification loop (harness-first agents) (2026)
    • what: Datadog describes agents that build systems under a harness (test setup) that a human defines. The human defines the system idea and invariants, and reviews the simulation harness.
    • number: Mental overhead roughly 2-3x the effort of writing the code itself
    • limits: A vendor post, not peer reviewed.
    • how much was read: parts read
    • source
    • record id: closing-the-verification-loop-2026
  • Verus guide (2026)
    • title: Verus Tutorial and Reference
    • what: Official Verus guide with advice on failing proofs.
    • limits: Guide content can change with the tool; no command was rerun here.
    • how much was read: parts read
    • source
    • record id: verus-guide-2026
  • 3SF model checking (2025)
    • title: Technical Report: Exploring Automatic Model-Checking of the Ethereum specification
    • what: The authors translate the Python spec of Ethereum’s 3-slot-finality (3SF) consensus protocol into TLA+ and use the Apalache model checker to test Accountable Safety: if two conflicting chains are both finalized, at least one third of validators can be shown to have broken a voting rule. They then add hand-made abstractions and re-encode the problem in SMT (CVC5) and Alloy to check larger instances.
    • number: Direct translation (Spec2): checking Accountable Safety timed out after more than 40 hours (Table 1)
    • number: Alloy with Kissat: Accountable Safety holds for up to 6 blocks; e.g. 5 blocks, 25 checkpoints, 12 votes in 234 s (Table 5)
    • number: CVC5: verified up to 5 blocks with 5 checkpoints (1h 40m) or 3 blocks with 6 checkpoints (74h) (Table 4)
    • number: A 7-block Alloy run went over 16 days without finishing
    • limits: Only the finality gadget and only Accountable Safety, on small bounded instances (at most 7 checkpoints and 24 votes); every validator has stake 1. The hand-made abstractions are not proved equal to the Python spec. Appendix A (translation rules) and B (soundness proofs) were skimmed, not read closely.
    • how much was read: parts read
    • source; notes: ## Exploring Automatic Model-Checking of the Ethereum specification (2
    • record id: 3sf-model-checking-2025
  • Anvil thesis (2025)
    • title: Building and Verifying Cloud Infrastructure Systems with State-Centric Reasoning (PhD dissertation)
    • what: The thesis proves liveness of Kubernetes controllers in Verus, using the Anvil framework. The human writes one general liveness formula, “eventually stable reconciliation”: if the desired state stops changing, the cluster eventually matches it and stays that way. The proof splits into two parts: the environment becomes stable, and the controller reaches the desired state.
    • number: about two person-months to verify the ZooKeeper controller, about two person-weeks for each of the other two
    • number: each controller takes around 2.5 person-months to implement and verify; proof-to-code ratio 4.5 to 7.4
    • number: ZooKeeper: executable 1,134 lines, proof 8,352 (ESR 7,245), trusted 950; RabbitMQ: executable 1,598, proof 7,228, trusted 548
    • number: framework: 5353 lines of reusable lemmas, 7817 lines of trusted code; 70+ temporal-rule lemmas, 60 Kubernetes-environment lemmas
    • limits: The controller must be a state machine whose actions are atomic (they cannot be interrupted). The proof trusts the environment model, the shim layer, external APIs, the verifier, the compiler and the OS. After verification, testing still found one bug. It came from an incomplete spec of a trusted ZooKeeper API. About 40% of the 111 pages were read.
    • how much was read: parts read
    • source
    • record id: anvil-thesis-2025
  • Clock-SI TLA+ (2025)
    • title: Formal modelling and analysis of Clock-SI with TLA+
    • what: A master’s thesis that models the Clock-SI protocol (snapshot isolation for a partitioned database using loosely synchronized clocks) in TLA+ in two versions, a detailed one and a simpler one, and uses the TLC model checker to test that the protocol gives Snapshot Isolation, stated with a client-centric specification.
    • number: Abstract model, Snapshot Isolation check: 2 keys, 2 partitions, 2 txns 3 s; 3 txns 3 min 28 s; 3 keys, 2 partitions, 3 txns 11 h 23 min 20 s; 3 keys, 3 partitions, 3 txns timed out (Table 10)
    • number: Detailed model: 3 keys, 2 partitions, 2 txns 21 min; most larger cases timed out (Table 9)
    • number: Symmetry and view features cut one 2-key, 2-partition, 3-txn state-space run from 2 h 54 min to 2 min 2 s (Table 8)
    • number: Machine: i7-7700HQ, 16 GB RAM; each time is the average of 3 runs; maximum runtime 12 hours
    • limits: Bounded to at most 3 transactions, keys, partitions; the target of 3/3/3 was not reached. The abstract model removes the message system, so it does not cover the real messaging. Only the safety property (Snapshot Isolation) is checked; no liveness. Chapters 2-3 (background) and the model listings in 4.1-4.2 were skimmed.
    • how much was read: parts read
    • source; notes: ## Formal modelling and analysis of Clock-SI with TLA+ (2025)
    • record id: clock-si-tla-2025
  • Dafny students with ChatGPT (Carreira et al.) (2025)
    • what: A study of Dafny students using ChatGPT.
    • limits: Gains depended on how good the prompts were.
    • how much was read: parts read
    • source
    • record id: dafny-students-with-chatgpt-2025
  • Korg thesis (2025)
    • title: Verification and Attack Synthesis for Network Protocols
    • what: Proves properties of three network-protocol pieces with theorem provers (Karn’s RTT algorithm and TCP’s timeout rule in Ivy and ACL2s, and Go-Back-N efficiency in ACL2s), model-checks TCP, DCCP and SCTP handshakes in SPIN, then builds Korg, a tool that searches for attacker behaviour that breaks a given property.
    • number: Handshake properties: TCP 4 (phi1-phi4), SCTP 10 (gamma1-gamma10), DCCP has its own set
    • number: Korg asked for at most 10 attacks per property; default search depth 600,000, maximum 2,400,000
    • number: TCP phi3 (peers do not get stuck) took 72 min to 223 min per attacker model; other TCP properties took seconds
    • number: SCTP: one patched-vs-unpatched check; with the CVE-2021-3772 patch, Korg finds no off-path attack, which proves the patch closes it for the model
    • limits: Models are small by design to avoid state-space explosion; the handshake models are not linked to the Ivy/ACL2s models. Korg handles one centralized attacker, not coordinated multi-process attackers, and is exact only for the model, not the real code. Models took long to write by hand.
    • how much was read: parts read
    • source; notes: ## Von Hippel thesis on protocol verification and attack synthesis (20
    • record id: korg-thesis-2025
  • On the Impact of Formal Verification on Software Development (2025)
    • what: Interviews with 14 Dafny users about how they write specs and proofs.
    • number: 14 interviews
    • how much was read: parts read
    • record id: on-the-impact-of-2025
  • PolySemist (2025)
    • title: Accelerating Protocol Synthesis and Detecting Unrealizability with Interpretation Reduction.
    • what: A tool that fills in the missing guards and updates of a half-written TLA+ distributed protocol (a sketch) so the protocol meets a safety or liveness property. It loops: the TLC model checker finds a counterexample, the tool rules out every candidate that shares it, and it skips candidates that behave the same on the states seen so far.
    • number: 7 benchmark protocols: 2PC, consensus, decentralized lock, lock server, sharded KV store, two reconfigurable Raft variants
    • number: faster than the previous tool Scythe in 160 of 171 realizable problems; total time about 9,000 s vs 32,000 s on those both solve
    • number: whole distributed-lock protocol (6 expressions over 2 actions) synthesized in 125 s; Scythe timed out at 1 hour
    • number: detected ‘no protocol exists’ in 80 of 123 unrealizable problems vs 16 for Scythe (easy 46/50, medium 21/35, hard 13/38)
    • limits: A human supplies the sketch (state variables, actions, hole grammars) and the property; results hold only for the chosen finite parameters (e.g. number of nodes), and the all-parameters step is left to TLAPS proofs from prior work. Termination is guaranteed only when each hole grammar has finitely many expressions up to interpretation equivalence.
    • how much was read: parts read
    • source; notes: ## PolySemist: protocol synthesis by sketching (2025)
    • record id: polysemist-2025
  • Scimitar (2025)
    • title: Interpretable Safety Verification of Distributed Protocols by Inductive Proof Decomposition
    • what: Scimitar breaks a proof into a graph of lemmas and transitions. This exposes where guidance is needed. The target is Raft LogMatching, on a modified model of about 600 TLA+ lines.
    • number: 21 hours, 33 total lemma nodes
    • number: grammar has 173 predicates
    • number: 33 lemma nodes
    • number: 173 grammar predicates
    • limits: The draft the notes inspected has a different title from earlier and later records, and a placeholder conference header. One property of an edited model is not a complete verification of Raft.
    • how much was read: parts read
    • source; notes: papers inspected
    • record id: scimitar-2025
  • Toward Practical Deductive Verification: Insights from a Qualitative Survey in Industry and Academia (2025)
    • what: Interviews of 30 practitioners (29 coded) about how they do deductive verification (proving code correct with logic).
    • number: 12 of 29 use refinement
    • number: Liveness named especially challenging by 3/29, global properties by 2/29
    • how much was read: parts read
    • source
    • record id: toward-practical-deductive-verification-2025
  • What’s in a Proof? Analyzing Expert Proof-Writing Processes in F* and Verus (2025)
    • what: Telemetry from 8 Microsoft Research experts writing proofs in F* and Verus. It finds three clusters of strategy. Planners who write the spec first were most successful.
    • number: 8 experts, 4 tasks, over 18,000 telemetry events
    • number: Verus about 9 verifier invocations per minute vs about 3.4 for F*
    • limits: The sample is small and the tasks are simple (binary search, sublist). There is no distributed or liveness task.
    • how much was read: parts read
    • source
    • record id: what-s-in-a-2025
  • FizzBee (2024)
    • title: Fizzbee, Liveness and Fairness (tutorial)
    • what: These are tool docs for FizzBee’s liveness syntax. ‘Always eventually’ means a good state recurs. ‘Eventually always’ means the system stabilises. Fairness is set per action: weak, strong, or unfair by default.
    • limits: The example is a toy. There is no CTL support. The notes cover about half of the docs.
    • how much was read: parts read
    • source; notes: FizzBee
    • record id: fizzbee-2024
  • Kondo (2024)
    • title: Inductive Invariants That Spark Joy: Using Invariant Taxonomies to Streamline Distributed Protocol Proofs
    • what: Kondo derives inductive invariants for Dafny protocol proofs from the protocol’s structure. This reduces the invariants the user must write.
    • number: Paxos: 418 lines, Kondo needs 20 user invariants, 777 total proof lines, 42.9 s
    • number: IronFleet 4,581 lines of Dafny and Verdi 50,000 lines of Coq for manual proofs
    • number: Paxos row: 631 model lines; 27 invariant clauses without Kondo vs 20 synchronous; 856 proof lines without Kondo vs 557 synchronous plus 220 modified
    • number: Table 1 p. 848: 10 systems (Echo Server, Ring Leader Election, Simplified Leader Election, Two-Phase Commit, Paxos, Flexible Paxos, Distributed Lock, ShardedKV, ShardedKV-Batched, Lock Server)
    • limits: Liveness proofs are beyond its scope. Line counts are not measured human hours.
    • how much was read: parts read
    • source; notes: papers inspected
    • record id: kondo-2024
  • Misconceptions in Finite-Trace and Infinite-Trace Linear Temporal Logic. (2024)
    • what: The study examines how people read and write linear temporal logic, across five deployments.
    • number: Writing a formula wrong: 21.11-25.00% (alpha), 33.68% (LTL-aware audience), 66.13% and 63.33% (student course)
    • number: Trace matching wrong: 1.85% to 27.24%
    • limits: The notes are unsure about the authors after the first. Percentages across different instruments cannot be compared.
    • how much was read: parts read
    • source
    • record id: misconceptions-in-finite-trace-2024
  • Verification and synthesis of distributed systems with weak synchronisation (2024)
    • what: A theory thesis on deciding, for processes that talk only by broadcast or only by taking and releasing locks, whether a system meets a property, and whether processes can be given local strategies that guarantee it. The trick is to pick a small description of what each process may do alone (an invariant or a set of patterns) and check whether any combination of such local runs can go wrong.
    • number: 254 pages, three models: broadcast networks of register automata, lock-sharing systems, dynamic lock-sharing systems
    • number: coverability for broadcast networks with data is complete for the class F_omega^omega, so needs non-primitive-recursive time
    • number: verification of lock-sharing systems with 2 locks per process or nested locks is NP-complete; synthesis is Sigma_2^P-complete
    • number: synthesis of local controllers is undecidable for general lock-sharing systems
    • limits: Pure decidability and complexity results with no tool or benchmark; the models are heavily restricted (only broadcast or only locks), and the author notes adding a shared variable makes the lock model undecidable. Read from the introduction, summaries and conclusions only, not the proofs.
    • how much was read: parts read
    • source; notes: ## Mascle thesis: weak synchronisation (2024)
    • record id: verification-and-synthesis-of-2024
  • Lessons from Formally Verified Deployed Software Systems (2023)
    • what: A survey of 32 formally verified deployed systems, mostly not distributed.
    • number: 22 of 32 depend on unverified code elements
    • number: HACL* proof-to-code ratio about 2, up to 6
    • number: Vericert: about 3 person-months implementation, 15 person-months proofs
    • limits: The notes’ author did not mine the full survey.
    • how much was read: parts read
    • source
    • record id: lessons-from-formally-verified-2023
  • Adore (2022)
    • title: Adore: Atomic Distributed Objects with Certified Reconfiguration
    • what: Adore describes a distributed protocol’s state at a high level. It tracks which parts are committed and which are not, and hides packet details. A Coq proof shows that a Raft-like protocol, SRaft, correctly implements Adore (a refinement). Adore covers several ways of changing cluster membership, chosen by parameters.
    • number: about 13.8k Coq lines overall; 2.5k for SRaft-to-Adore refinement
    • number: 2 weeks for CADO safety plus another 3 for reconfiguration, five person-weeks, abstract safety only (§7, PDF p.13)
    • number: 13.8K lines for the full Raft development
    • limits: The proof is about the protocol, not application code. It makes no claim that the system eventually makes progress or stays available.
    • how much was read: parts read
    • source; notes: papers; notes: Adore: Atomic Distributed Objects with Certified Reconfiguration
    • record id: adore-2022
  • Aneris causal memory (2021)
    • title: Distributed Causal Memory: Modular Specification and Verification in Higher-Order Distributed Separation Logic
    • what: Specifies a causally consistent database (one where an effect is never seen before its cause). Servers and clients are proved separately, and a session manager adds guarantees for each client on top.
    • limits: It proves the code does the right thing through separate specs for each part. It makes no promise about response time. The collection filename says 2022 but the paper says 2021.
    • how much was read: parts read
    • source; notes: Distributed Causal Memory: Modular Specification and Verification in H
    • record id: aneris-causal-memory-2021
  • ShardStore (2021)
    • title: Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3
    • what: Executable reference models and checks for the S3 ShardStore storage node.
    • number: Reference models about 1% of implementation code
    • number: Checks and harnesses 12% of the code base
    • number: Prevented 16 issues from reaching production
    • number: 18% of reference model and harness code written by the engineering team
    • limits: Passing the checks does not mean the code is correct.
    • how much was read: parts read
    • source; notes: papers; notes: Using Lightweight Formal Methods to Validate a Key-Value Storage Node
    • record id: shardstore-2021
  • Elle (2020)
    • title: Elle: Inferring Isolation Anomalies from Experimental Observations
    • what: A test-time checker that runs random transactions against a database, records what clients saw, and rebuilds a dependency graph between transactions. A cycle in that graph is a proof that the database broke its claimed isolation level.
    • number: Found anomalies in all 4 databases tested: TiDB, YugaByte DB, FaunaDB, Dgraph
    • number: Checks histories of hundreds of thousands of transactions in tens of seconds; Knossos often fails after a few hundred
    • number: Linear time in history length
    • limits: Needs generated workloads where reads reveal the full write history (such as list append). Ignores predicates, so it cannot separate repeatable read from serializability. It finds bugs, not proof that a database is correct.
    • how much was read: parts read
    • source; notes: ## Elle isolation checker (2020)
    • record id: elle-2020
  • Pretend Synchrony / Goolong (2019)
    • title: Pretend synchrony: synchronous verification of asynchronous distributed programs
    • what: Verifies Go distributed programs by automatically rewriting them into an equivalent synchronous program (messages become assignments), then checking ordinary verification conditions with the Z3 solver. Four case studies: two-phase commit, Raft leader election, single-decree Paxos, Multi-Paxos key-value store.
    • number: manual invariant annotations reduced by 6x versus Dafny
    • number: check time 1.73 s total vs 1455.84 s in Dafny for the three protocols
    • number: Paxos 504 lines of Go, 14 loop-invariant lines, 1.51 s; Dafny 72 invariant lines, 1141.35 s
    • number: Multi-Paxos KV: 847 Go lines, 1.64 s check, 118.5 req/ms, within 1.5-3x of unverified EPaxos code
    • limits: Safety only, no liveness. Needs structured loops, symmetric process ids, typed channels, pairwise communication and round non-interference; rules out Multi-Paxos stable-leader optimization, Stoppable Paxos and ring topologies such as Chord.
    • how much was read: parts read
    • source; notes: Pretend Synchrony (2019)
    • record id: pretend-synchrony-goolong-2019
  • QED at Large (2019)
    • title: QED at Large: A Survey of Engineering of Formally Verified Software
    • what: A survey of proof engineering (building and maintaining machine-checked proofs).
    • how much was read: parts read
    • source; notes: S12
    • record id: qed-at-large-2019
  • Disel (2018)
    • title: Programming and Proving with Distributed Protocols
    • what: Proves distributed components and their clients in Coq against protocol descriptions, and composes their contracts. A protocol can be strengthened for one client without redoing the component proofs.
    • number: about 4,500 lines of framework metatheory
    • number: two-phase commit core: 997 definition/spec lines and 2,113 proof lines; nine person-days
    • number: trusted OCaml shim about 250 lines
    • number: nine person-days for the core two-phase-commit development (§8, PDF p.24)
    • limits: Safety only.
    • how much was read: parts read
    • source; notes: papers and boundaries; notes: Programming and Proving with Distributed Protocols
    • record id: disel-2018
  • Iris (2018)
    • title: Iris from the ground up: A modular foundation for higher-order concurrent separation logic
    • what: This paper explains a checked framework for reasoning about concurrent programs. Ghost resources (resources that exist only in the proof) are tied to program state through invariants.
    • limits: The paper covers Iris 3.1. The current project has newer references.
    • how much was read: parts read
    • source; notes: S7
    • record id: iris-2018
  • CertiKOS (2016)
    • title: CertiKOS: An Extensible Architecture for Building Certified Concurrent OS Kernels
    • what: CertiKOS specifies an interface and the visible events at each kernel layer. It proves that a module can stand in for its specification in the contexts it allows (this is called contextual refinement). The mC2 kernel is proved in Coq.
    • number: Under 2 person-years for supporting concurrency
    • number: 6500 lines of C and x86 assembly
    • limits: The 2 person-years is the cost of adding concurrency support, not the cost of a whole new kernel.
    • how much was read: parts read
    • source; notes: S9
    • record id: certikos-2016
  • Chapar (2016)
    • title: Chapar: Certified Causally Consistent Distributed Key-Value Stores
    • what: Chapar states the public causal-visibility rule separately from the store internals. The rule says that if an update is visible, its dependencies are visible. The authors prove two store algorithms and extract OCaml. They verify client examples, such as publishing a photo before a post that refers to it.
    • limits: It trusts serialization and the runtime infrastructure.
    • how much was read: parts read
    • source; notes: papers; notes: Chapar: Certified Causally Consistent Distributed Key-Value Stores
    • record id: chapar-2016
  • F* (2016)
    • title: Dependent Types and Multi-monadic Effects in F*
    • what: F* is a language that mixes effectful programming, contracts, dependent types and solver automation.
    • how much was read: parts read
    • source; notes: S20
    • record id: f-2016
  • Verdi Raft (2016)
    • title: Planning for Change in a Formal Verification of the Raft Consensus Protocol
    • what: The authors complete the proof of Raft state-machine safety in Verdi. They manage changes across interdependent invariants by hiding definitions behind interface lemmas.
    • number: 90 system invariants discovered and proved
    • number: about 45000 additional lines on top of an earlier roughly 5,000-line proof
    • number: 530 lines of code and 50,000 lines of proof
    • number: 530 lines of code and 50,000 lines of proof (Raft development only, §5, PDF p.5)
    • limits: It proves safety only. It excludes dynamic membership and log compaction.
    • how much was read: parts read
    • source; notes: S34
    • record id: verdi-raft-2016
  • Viotti-Vukolić survey (2016)
    • title: Consistency in Non-Transactional Distributed Storage Systems
    • what: A map of definitions of consistency models (causal, eventual and others) for non-transactional storage.
    • limits: It excludes transactional semantics. It is not the primary source for each model.
    • how much was read: parts read
    • source; notes: S24
    • record id: viotti-vukolic-survey-2016
  • AWS formal methods (2015)
    • title: Use of Formal Methods at Amazon Web Services (How Amazon Web Services Uses Formal Methods)
    • what: AWS engineers used TLA+ and TLC to explore distributed designs and find subtle bugs, including in replication and recovery designs. It is the clearest industrial statement of the gap between model and code.
    • limits: It checks designs only and does not prove the deployed code correct. The linked manuscript is dated 29 September 2014 and differs from the final publication.
    • how much was read: parts read
    • source; notes: P01. How Amazon Web Services Uses Formal Methods; notes: papers
    • record id: aws-formal-methods-2015
  • Matichuk et al. (seL4 proof size study) (2015)
    • what: The study compares the size of seL4 proofs with the size of the statements they prove.
    • number: 15,018 lemmas, about 215,000 lines of proof
    • how much was read: parts read
    • record id: matichuk-et-al-sel4-2015
  • Proof productivity (2014)
    • title: Productivity for Proof Engineering
    • what: Fits proof effort to proof size.
    • number: Total Effort = 9.98 + 3.35*Final Size (R^2 = 0.914; person-weeks and kilo-lines of proof)
    • limits: Proof lines are a limited measure. The fit applies to one particular population of projects. It is not a universal conversion.
    • how much was read: parts read
    • source; notes: S36
    • record id: proof-productivity-2014
  • How to Write a 21st Century Proof (2012)
    • what: A structured, hierarchical style for writing proofs.
    • how much was read: parts read
    • record id: how-to-write-a-2012
  • seL4 process study (2012)
    • title: Large-Scale Formal Verification in Practice: A Process Perspective
    • what: A study of the process of verifying seL4.
    • number: Design verification consumed roughly 60-70% of time and effort
    • number: Less than 14 person-years for kernel design, development and verification
    • number: Integrity and authority confinement took 10 person months
    • number: Maintenance about one full-time person
    • how much was read: parts read
    • source; notes: S35
    • record id: sel4-process-study-2012
  • CRDT study (2011)
    • title: A comprehensive study of Convergent and Commutative Replicated Data Types
    • what: It gives sufficient conditions for replicated objects to converge, both state-based and operation-based. The conditions are merge and commutation laws plus assumptions about message delivery.
    • how much was read: parts read
    • source; notes: S25
    • record id: crdt-study-2011
  • Dafny (2010)
    • title: Dafny: An Automatic Program Verifier for Functional Correctness
    • what: The paper presents the Dafny language and verifier: contracts, how the heap is modeled, and how programs are encoded for the solver.
    • how much was read: parts read
    • source; notes: S21
    • record id: dafny-2010
  • Hyperproperties (2010)
    • what: Defines hyperproperties, which are specifications over sets of executions. Shows that refinement can break them, for example by leaking a secret. Shows that k-safety hyperproperties reduce to safety on k copies of the system.
    • limits: A mathematical classification only. No runnable artifact. k-safety does not cover all hypersafety, and the paper does not solve hyperliveness (the progress counterpart).
    • how much was read: parts read
    • source; notes: wishes comparing several executions
    • record id: hyperproperties-2010
  • seL4 (2009)
    • title: seL4: Formal Verification of an OS Kernel
    • what: This is a proof in Isabelle that a microkernel’s implementation refines (correctly implements) its spec.
    • number: 8,700 lines of C
    • number: 200,000 lines of Isabelle script
    • number: Abstract spec took about 4 person months
    • number: Refinement statements at most 20% of effort
    • limits: It is a historical baseline. The 2014 paper has the expanded stack and the effort analysis.
    • how much was read: parts read
    • source; notes: S11
    • record id: sel4-2009
  • Environment Assumptions for Synthesis (2008)
    • what: This work computes environment assumptions from a spec alone, so that a conditional spec becomes implementable. It first forbids unsafe environment moves. It then adds strong fairness (an action that is enabled infinitely often must eventually run) to some of the remaining moves.
    • number: smallest set of fair edges is NP-hard (Theorem 11)
    • number: safety sufficiency check polynomial; fairness minimization yields a set with no removable subset, not the smallest (Theorem 12)
    • limits: No unique maximal sufficient assumption exists. The results are for finite reactive games, and there is no distributed benchmark. It does not certify an implementation that was already chosen.
    • how much was read: parts read
    • source
    • record id: environment-assumptions-for-synthesis-2008
  • Separation logic (2002)
    • title: Separation Logic: A Logic for Shared Mutable Data Structures
    • what: Adds a separating conjunction P * Q for assertions about disjoint parts of memory. Adds a frame rule, so the proof of a small component can be reused inside a larger heap.
    • how much was read: parts read
    • source; notes: S6
    • record id: separation-logic-2002
  • Specifying Systems (2002)
    • what: This book builds TLA+ specifications from state, initial conditions and allowed steps. It then adds requirements that something eventually happens, and fairness (an action that stays possible eventually runs).
    • limits: The notes read only chapter 8 and the passages on refinement. A spec that covers only safety permits a system to do nothing. Fairness on a combined action can miss the starvation of one request.
    • how much was read: parts read
    • source
    • record id: specifying-systems-2002
  • Specifying Systems (2002)
    • title: Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers
    • what: A book on TLA+. Chapters 2-5 develop initial states and allowed next steps. Chapters 8 and 14 cover progress conditions and model checking.
    • limits: Translation does not decide which failures or observations the human cares about (the notes’ inference).
    • how much was read: parts read
    • source; notes: human specification practice; notes: P03. Specifying Systems
    • record id: specifying-systems-2002-2
  • Property Specification Patterns (1999)
    • title: Patterns in Property Specifications for Finite-state Verification
    • what: This is a catalog of reusable requirement patterns, about what occurs and in what order. It also lists scopes: global, before, after, between, and after-until. Each pattern is mapped to formal languages for describing behavior over time. The authors also surveyed real specifications.
    • limits: The notes read the authors’ pattern repository, not the ICSE PDF. The repository labels a formula about all branching futures (AG/AF) as LTL.
    • how much was read: parts read
    • source
    • record id: property-specification-patterns-1999
  • Forward/backward simulations (1995)
    • title: Forward and Backward Simulations, Part I: Untimed Systems
    • what: It defines relations between steps of two systems (forward and backward simulations). They prove that one system’s visible behaviors are included in the other’s. They are for cases where a plain abstraction function cannot match the choices the systems make.
    • how much was read: parts read
    • source; notes: S3
    • record id: forward-backward-simulations-1995
  • TLA (1994)
  • Refinement mappings (1991)
    • title: The Existence of Refinement Mappings
    • what: It shows that suitable refinement mappings (functions from implementation states to spec states) exist once auxiliary variables are added under stated hypotheses. It covers three obstacles: history, prophecy (needing to know the future) and step granularity.
    • limits: It is a completeness result. It is not an algorithm that finds the variables or the mapping. The notes’ author did not fully read the proofs.
    • how much was read: parts read
    • source; notes: S2; notes: connecting different descriptions of the same behavior
    • record id: refinement-mappings-1991
  • DLS partial synchrony (1988)
    • title: Consensus in the Presence of Partial Synchrony
    • what: It defines two ways to weaken synchrony. In one, the timing bounds are fixed but unknown. In the other, the bounds are known but hold only after an unknown global stabilization time. It gives consensus algorithms whose agreement always holds and whose termination holds after stabilization.
    • number: crash/omission consensus needs N >= 2t+1 and Byzantine needs N >= 3t+1 in the partially synchronous columns of Table I
    • number: Algorithm 1: all correct processors decide by round GST + 4(N+1) in the basic round model
    • number: Theorem 4.1(b): N >= 3t+1
    • limits: The proofs are on paper, with no machine-checked artifact. The bound is counted in rounds of the basic round model, not in seconds. A timeout is not evidence of a crash.
    • how much was read: parts read
    • source; notes: Dwork–Lynch–Stockmeyer partial synchrony; notes: Consensus: where the assumptions enter the proof
    • record id: dls-partial-synchrony-1988
  • FLP (1985)
    • title: Impossibility of Distributed Consensus with One Faulty Process
    • what: Shows that no deterministic asynchronous consensus protocol can guarantee a decision on every allowed execution if one process may stop, even when messages are always eventually delivered.
    • limits: This is an impossibility result under its stated assumptions only. Randomization or eventual synchrony changes the problem.
    • how much was read: parts read
    • source; notes: S26; notes: Consensus: where the assumptions enter the proof
    • record id: flp-1985
  • Byzantine Generals (1982)
    • title: The Byzantine Generals Problem
    • what: The paper defines faulty participants that may act arbitrarily and give different information to different peers. It also separates different assumptions about messages.
    • limits: The claimed thresholds depend on the paper’s assumptions about messages and synchrony.
    • how much was read: parts read
    • source; notes: S27
    • record id: byzantine-generals-1982
  • Sequential consistency (1979)
    • title: How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs
    • what: This is the original definition of sequential consistency: there is one sequential order that preserves each processor’s program order. It has no real-time constraint.
    • how much was read: parts read
    • source; notes: S23
    • record id: sequential-consistency-1979
  • Hoare logic (1969)
    • title: An Axiomatic Basis for Computer Programming
    • what: Introduces reasoning about programs with assertions: if P holds before the program runs and the program finishes, then Q holds after.
    • limits: A historical source. The notes spell out the modern distinction between partial correctness (right if the program ends) and total correctness (right, and it ends).
    • how much was read: parts read
    • source; notes: S5
    • record id: hoare-logic-1969
  • Alloy
    • what: A modelling tool that describes a system with relations. It checks models only up to a chosen size limit (the scope). Alloy 6 adds mutable state, a temporal logic and solvers.
    • limits: The size limit is part of what a result means. A passing check is not a proof about an implementation the model is not tied to.
    • how much was read: parts read
    • source; notes: Alloy and Event-B
    • record id: alloy
  • Choreo
  • Dafny reference manual, Sec 13.7
    • what: A debugging recipe: assert the postcondition before the return and move the assertion up. Measure how brittle a proof is with dafny measure-complexity.
    • how much was read: parts read
    • record id: dafny-reference-manual-sec
  • Event-B
    • title: Event-B / Rodin
    • what: Event-B builds models from sets, with proof obligations and refinement between levels of the model. The code-generation page discusses Tasking Event-B, which aims at executable implementations.
    • limits: There are several generation approaches, each with different restrictions. Nothing proves in general that Event-B refinements give verified distributed Rust.
    • how much was read: parts read
    • source; notes: Alloy and Event-B
    • record id: event-b
  • Quint
    • what: A specification language with simulation and model-checker integrations. The current docs list both TLC and Apalache.
    • limits: Like TLA+, it checks a model, not the code.
    • how much was read: parts read
    • source; notes: Quint, Apalache, Atomkraft, Modelator
    • record id: quint
  • quint-llm-kit
  • Verus guide: smaller pieces
    • title: Verus Tutorial and Reference: Breaking proofs into smaller pieces
    • what: This is a documentation recipe. It moves a subproof into a lemma and keeps the solver context small.
    • limits: The notes found no current chapter named ‘structuring system proofs’.
    • how much was read: parts read
    • source; notes: D1
    • record id: verus-guide-smaller-pieces
  • Verus state machines
    • title: Verus State Machines Tutorial and Reference
    • what: Shows how to model a program as a tokenized state machine. Shows how the tool checks the inductive conditions (true at the start, preserved by each step) for each initializer and transition. A counter example shows why a stronger invariant is needed.
    • how much was read: parts read
    • source; notes: D2
    • record id: verus-state-machines
  • Verus TCB guide
    • title: Verus: Assumptions and trusted components
    • what: The guide lists the mechanisms that introduce assumptions in Verus: assume, external_body, external specifications and external trait implementations. It also lists the caveats.
    • how much was read: parts read
    • source; notes: D4
    • record id: verus-tcb-guide
  • COBALT-TLA (2026)
    • title: COBALT-TLA: A Neuro-Symbolic Verification Loop for Cross-Chain Bridge Vulnerability Discovery
    • what: Cobalt pairs an LLM with a TLC REPL. The LLM generates bounded TLA+ models of cross-chain bridges and gets structured traces back so it can repair them. The work was motivated by bugs in the order of events in cross-chain bridges.
    • number: three bridge targets including Nomad
    • limits: This is a model-checking workflow. Nothing proves that the generated spec is equivalent to the bridge code.
    • how much was read: only abstract or first pages read
    • source
    • record id: cobalt-tla-2026
  • Formal Methods in Industry: A Critical Evaluation of Their Use at Amazon Web Services (2026)
    • what: A critical evaluation of how AWS uses formal methods.
    • limits: The review notes read the abstract only and did not fetch the PDF.
    • how much was read: only abstract or first pages read
    • source
    • record id: formal-methods-in-industry-2026
  • ProGS (2026)
    • title: Formal Model Construction Guided by Model-Based Proof Sketches
    • what: An LLM builds formal models guided by proof sketches, which are trees that are generated and repaired. This replaces generate-and-repair.
    • number: 27-system benchmark
    • limits: The review notes read the abstract only. The benchmark number comes from an earlier summary.
    • how much was read: only abstract or first pages read
    • source
    • record id: progs-2026
  • Specifications for Humans, Agents, and Tooling (2026)
    • what: Describes the Bosque API ecosystem for agent-driven development. It has polyglot specs, test generation, validation and sandboxing. Specs are shared artifacts for people, agents and tools.
    • limits: A position on tooling. No refinement theorem and no evaluation on a distributed protocol. Not evidence that intent can be recovered automatically.
    • how much was read: only abstract or first pages read
    • source
    • record id: specifications-for-humans-agents-2026
  • Crash-stop MPST (2025)
    • title: Crash-Stop Failures in Asynchronous Multiparty Session Types
    • what: Extends asynchronous multiparty session types with crash-stop failures, crash handling branches, and optional reliability assumptions. It proves sound and complete correspondence between global/local semantics and derives deadlock freedom, protocol conformance, and liveness for well-typed processes under crashes.
    • number: Covers reliability from no failures to arbitrary process crashes
    • number: Theorems establish subject reduction, session fidelity, deadlock freedom, and liveness
    • number: Formal development spans 71-page LMCS article
    • limits: Processes crash permanently; link failures and crash-recovery are future work. Results concern typed session calculus rather than implementation-level consensus protocols.
    • how much was read: only abstract or first pages read
    • source
    • record id: crash-stop-mpst-2025
  • FASTRIC (2025)
    • title: FASTRIC: Prompt Specification Language for Verifiable LLM Interactions
    • what: A prompt language that makes explicit the finite-state machine hidden in a multi-turn LLM conversation. This allows checking that a conversation follows the protocol, using execution traces.
    • limits: Checks that a run follows the protocol. It does not prove theorems. The pages inspected had no TLA+ or Verus refinement, and no progress proof.
    • how much was read: only abstract or first pages read
    • source
    • record id: fastric-2025
  • QED in Context (2025)
    • title: QED in Context: An Observation Study of Proof Assistant Users
    • what: An observation study of 30 Rocq and Lean users doing everyday work.
    • number: 30 participants
    • limits: Only the abstract was read. It is not about liveness or distributed systems.
    • how much was read: only abstract or first pages read
    • source
    • record id: qed-in-context-2025
  • Super-V (2025)
    • title: Bolt-On Strong Consistency: Specification, Implementation, and Verification
    • what: It verifies a Raft-like replicated store built on a weak replicated store. SMT checks local, stable preconditions on updates.
    • limits: Only the abstract was read. The PDF was not obtained.
    • how much was read: only abstract or first pages read
    • source
    • record id: super-v-2025
  • TLA+ communication module (2025)
    • title: A Practical TLA+ Library for Designing and Verifying Distributed Systems
    • what: A TLA+ library of communication-channel primitives with selectable faults. It was used to verify atomic broadcast properties and Deferred Update Replication.
    • limits: The full text is behind a subscription, so the review notes have only abstract-level claims. The checked properties, counts and effort are unverified. The repository tests are model checks with TLC, not proofs that code matches the model.
    • how much was read: only abstract or first pages read
    • source; notes: A Practical TLA+ Library for Designing and Verifying Distributed Syste
    • record id: tla-communication-module-2025
  • Formal Verification of Digital Twins with TLA and Information Leakage Control (2024)
    • what: A TLA+ model that abstracts physical and communication processes into atomic state transitions. It explicitly assumes that messages are eventually delivered correctly.
    • limits: Delivery is assumed, not proved.
    • how much was read: only abstract or first pages read
    • source; notes: digital twins with TLA+
    • record id: formal-verification-of-digital-2024
  • QuickSilver (2021)
    • title: QuickSilver: Modeling and Parameterized Verification for Distributed Agreement-Based Systems
    • what: Quicksilver abstracts verified agreement protocols. It applies the abstractions to application case studies, using parameterized verification (one proof covers any number of nodes).
    • limits: The notes cite only the abstract. Procedure note: check that the abstractions preserve the application properties the paper claims, not only the agreement primitive.
    • how much was read: only abstract or first pages read
    • source
    • record id: quicksilver-2021
  • TLA+ video course (2021)
    • what: Lamport’s official course page lists a sequence of TLA+ lessons covering behaviors, safety, liveness, fairness, invariants and proofs, with downloadable video material.
    • limits: Course page is instructional material, not an evaluation or a new result.
    • how much was read: only abstract or first pages read
    • source
    • record id: tla-video-course-2021
  • Paxos Commit (2006)
    • title: Consensus on Transaction Commit
    • what: Defines Two-Phase Commit and Paxos Commit, with TLA+ specifications of their safety properties, and explains when Paxos Commit makes progress despite coordinator failures.
    • number: Paxos Commit uses 2F+1 coordinators and makes progress when at least F+1 work
    • number: Two-Phase Commit is the F=0 special case
    • limits: The paper’s formal specifications omit liveness assumptions in the appendix; progress depends on the stated failure and majority assumptions.
    • how much was read: only abstract or first pages read
    • source
    • record id: paxos-commit-2006
  • Unreliable Failure Detectors for Reliable Distributed Systems (1996)
    • what: It characterizes unreliable failure detectors by completeness and accuracy. It shows that consensus can be solved in asynchronous crash systems even when detectors make infinitely many mistakes.
    • limits: Only the abstract was checked. The result on the weakest detector belongs to a companion paper.
    • how much was read: only abstract or first pages read
    • source
    • record id: unreliable-failure-detectors-for-1996
  • A compositional proof framework for FRETish requirements.
    • what: ACM Reference Format: Structured natural languages provide a trade space between Esther Conrad, Laura Titolo, Dimitra Giannakopoulou, Thomas Pressburger, and Aaron Dutle. 2022. A Compositional Proof Frame- ambiguous natural languages that make up most written work for FRETish Requirements.
    • how much was read: only abstract or first pages read
    • source
    • record id: a-compositional-proof-framework
  • A Misconception-Driven Adaptive Tutor for Linear Temporal Logic
    • what: . Linear Temporal Logic (LTL) is used widely in veriïŹcation, planning, and more. Unfortunately, users often struggle to learn it.
    • how much was read: only abstract or first pages read
    • source
    • record id: a-misconception-driven-adaptive
  • A Natural Formalized Proof Language
    • what: . Artificial intelligence assisted mathematical proof has become a highly focused area nowa- days. One key problem in this field is to generate formal mathematical proofs from natural language proofs.
    • how much was read: only abstract or first pages read
    • source
    • record id: a-natural-formalized-proof
  • A Pyramid Of (Formal) Software Verification.
    • what: . Over the past few years there has been signiïŹcant progress in the various ïŹelds of software veriïŹcation resulting in many useful tools and successful deployments, both academic and commercial. However much of the work describing these tools and ideas is written by and for the research community.
    • how much was read: only abstract or first pages read
    • source
    • record id: a-pyramid-of-formal
  • An Executable Sequential Specification for Spark Aggregation
    • what: . Spark is a new promising platform for scalable data-parallel compu- tation. It provides several high-level application programming interfaces (APIs) to perform parallel data aggregation.
    • how much was read: only abstract or first pages read
    • source
    • record id: an-executable-sequential-specification
  • Are Users More Willing to Use Formally Verified Password Managers?
    • what: . Formal verification has recently been increasingly used to prove the correctness and security of many applications. It is attractive because it can prove the absence of errors with the same certainty as mathematicians proving theorems.
    • how much was read: only abstract or first pages read
    • source
    • record id: are-users-more-willing
  • Bounded Exhaustive Search of Alloy Specification Repairs.
    • what: Bounded Exhaustive Search of Alloy Specification Repairs Simón Gutiérrez Brida∗† , Germán Regis∗, Guolong Zheng‡, Hamid Bagheri‡ , ThanhVu Nguyen‡, Nazareno Aguirre∗† , Marcelo Frias†§ ∗ Department of Computer Science, FCEFQyN, University of Rı́o Cuarto, Argentina † National Council for Scientific and Technical Research (CONICET), Argentina ‡ Department of Computer Science & Engineering, University of Nebraska-Lincoln, USA § Department of Software Engineering, Buenos Aires Institute of Technology, Argentina arXiv:2103.00327v1 [cs.SE] 27 Feb 2021 Abstract—The rising popularity of declarative languages and in place of another, leading to incorrect specifications that the hard to debug nature thereof have motivated the need do not capture the developer’s intentions [3]. These kinds of for applicable, automated repair techniques for such languages. mistakes share characteristics with program defects.
    • limits: Read from the saved open PDF; this record uses the abstract/opening section and preserves the exact extracted quote below.
    • how much was read: only abstract or first pages read
    • source
    • record id: bounded-exhaustive-search-of
  • ’Cause I’m strong enough: reasoning about consistency choices in distributed systems.
    • what: use. Ideally, we would like replicated databases to provide strong Large-scale distributed systems often rely on replicated databases consistency, i.e., to behave as if a single centralised node handles that allow a programmer to request different data consistency guar- all operations. However, achieving this ideal usually requires syn- antees for different operations, and thereby control their perfor- chronisation among replicas, which slows down the database and mance.
    • how much was read: only abstract or first pages read
    • source
    • record id: cause-i-m-strong
  • Counter-strategy guided refinement of GR(1) temporal logic specifications
    • what: Counter-Strategy Guided Refinement of GR(1) Temporal Logic Specifications Rajeev Alur, Salar Moarref, and Ufuk Topcu University of Pennsylvania, Philadelphia, USA. {alur,moarref,utopcu}@seas.upenn.edu Abstract—The reactive synthesis problem is to find a finite- to give the user insight into the specification. They also state controller that satisfies a given temporal-logic specification provide ways to correct the specification.
    • how much was read: only abstract or first pages read
    • source
    • record id: counter-strategy-guided-refinement
  • Developing Verified Programs with Dafny
    • what: Developing Verified Programs with Dafny K. Rustan M. Leino Microsoft Research, Redmond, WA, USA leino@microsoft.com Abstract.
    • how much was read: only abstract or first pages read
    • source
    • record id: developing-verified-programs-with
  • Fast and Reliable Formal Verification of Smart Contracts with the Move Prover.
    • what: . The Move Prover (MVP) is a formal verifier for smart contracts written in the Move programming language. MVP has an expressive specifi- cation language, and is fast and reliable enough that it can be run routinely by developers and in integration testing.
    • how much was read: only abstract or first pages read
    • source
    • record id: fast-and-reliable-formal
  • Formally Modelling the Rijkswaterstaat Tunnel Control Systems in a Constrained Industrial Environment
    • what: Formally Modelling the Rijkswaterstaat Tunnel Control Systems in a Constrained Industrial Environment Kevin H.J. Jilissen Peter Dieleman Jan Friso Groote Rijkswaterstaat Rijkswaterstaat Eindhoven University of Technology Utrecht, the Netherlands Utrecht, the Netherlands Eindhoven, the Netherlands Eindhoven University of Technology peter.dieleman@rws.nl j.f.groote@tue.nl Eindhoven, the Netherlands kevin.jilissen@rws.nl Rijkswaterstaat, the National Dutch body responsible for infrastructure, recognised the importance of formal modelling and set up a program to model the control of road tunnels. This is done to improve the standardisation of tunnel control and make communication with suppliers smoother.
    • how much was read: only abstract or first pages read
    • source
    • record id: formally-modelling-the-rijkswaterstaat
  • LEGOS-SLEEC: Tool for Formalizing and Analyzing Normative Requirements.
    • what: —Systems interacting with humans, such as assistive engineers [2]–[5]. For instance, the requirement Ra is ex- robots or chatbots, are increasingly integrated into our society. pressed in SLEEC DSL rule r2 in Tbl.
    • how much was read: only abstract or first pages read
    • source
    • record id: legos-sleec-tool-for
  • Local Verification of Global Invariants in Concurrent Programs.
    • what: . We describe a practical method for reasoning about realistic concurrent programs. Our method allows global two-state invariants that restrict update of shared state.
    • how much was read: only abstract or first pages read
    • source
    • record id: local-verification-of-global
  • Mechanising blockchain consensus
    • what: the previous state of the node or the entire network (we We present the first formalisation of a blockchain-based intentionally leave out the details of what can go into distributed consensus protocol with a proof of its consis- a transaction, as they are application-specific); a node tency mechanised in an interactive proof assistant. can also (b) create and broadcast a block that contains Our development includes a reference mechanisation the encoding of a certain vector of transactions, cre- of the block forest data structure, necessary for imple- ated locally or received via messages of type (a) from menting provably correct per-node protocol logic. We other nodes.
    • limits: Abstract-level reading from openly available PDF; detailed limitations require full paper review.
    • how much was read: only abstract or first pages read
    • source
    • record id: mechanising-blockchain-consensus
  • On the Industrial Uptake of Formal Methods in the Railway Domain
    • what: . The railway sector has seen a large number of successful ap- plications of formal methods and tools. However, up-to-date, structured information about the industrial usage and needs related to formal tools in railways is limited.
    • limits: Abstract-level reading from openly available PDF; detailed limitations require full paper review.
    • how much was read: only abstract or first pages read
    • source
    • record id: on-the-industrial-uptake
  • Practical Deductive Verification of OCaml Programs.
    • what: . In this paper, we provide a comprehensive, hands-on tutorial on how to apply deductive veriïŹcation to programs written in OCaml. In particular, we show how one can use the GOSPEL speciïŹcation lan- guage and the Cameleer tool to conduct mostly-automated veriïŹcation on OCaml code.
    • how much was read: only abstract or first pages read
    • source
    • record id: practical-deductive-verification-of
  • RATSY – A New Requirements Analysis Tool with Synthesis
    • what: . Formal speciïŹcations play an increasingly important role in system design-ïŹ‚ows. Yet, they are not always easy to deal with.
    • how much was read: only abstract or first pages read
    • source
    • record id: ratsy-a-new-requirements
  • Refinement-Based Specification and Security Analysis of Separation Kernels
    • what: —Assurance of information-flow security by formal methods is mandated in security certification of separation kernels. As an industrial standard for improving safety, ARINC 653 has been complied with by mainstream separation kernels. Due to the new trend of integrating safe and secure functionalities into one separation kernel, security analysis of ARINC 653 as well as a formal specification with security proofs are thus significant for the development and certification of ARINC 653 compliant Separation Kernels (ARINC SKs).
    • how much was read: only abstract or first pages read
    • source
    • record id: refinement-based-specification-and
  • Reusable Specification Patterns for Verification of Resilience in Autonomous Hybrid Systems
    • what: . Autonomous hybrid systems are systems that combine dis- crete and continuous behavior with autonomous decision-making, e.g., using reinforcement learning. Such systems are increasingly used in safety-critical applications such as self-driving cars, autonomous robots or water supply systems.
    • how much was read: only abstract or first pages read
    • source
    • record id: reusable-specification-patterns-for
  • Semantics, Specification, and Bounded Verification of Concurrent Libraries in Replicated Systems.
    • what: . Geo-replicated systems provide a number of desirable prop- erties such as globally low latency, high availability, scalability, and built- in fault tolerance. Unfortunately, programming correct applications on top of such systems has proven to be very challenging, in large part because of the weak consistency guarantees they oïŹ€er.
    • how much was read: only abstract or first pages read
    • source
    • record id: semantics-specification-and-bounded
  • Simpler Specifications and Easier Proofs of Distributed Algorithms Using History Variables
    • what: This paper studies specifications and proofs of distributed algorithms when only message history variables are used, using the Basic Paxos and Multi-Paxos algorithms for distributed consensus as precise case studies. We show that not using and main- taining other state variables yields simpler specifications that are more declarative and easier to understand. It also allows easier proofs to be developed by needing fewer invariants and facilitating proof derivations.
    • limits: Abstract-level reading from openly available PDF; detailed limitations require full paper review.
    • how much was read: only abstract or first pages read
    • source
    • record id: simpler-specifications-and-easier
  • Spreadsheet-based Configuration of Families of Real-Time Specifications
    • what: Spreadsheet-based Configuration of Families of Real-Time Specifications JosĂ© Proença David Pereira Giann Spilere Nandi CISTER and University of Porto, Portugal CISTER, Polytechnic Institute of Porto, Portugal jose.proenca@fc.up.pt {drp,giann}@isep.ipp.pt Sina Borrami Jonas Melchert Alstom {sina.borrami,jonas.melchert}@alstomgroup.com 1 Introduction Model checking real-time systems is complex. This particular work was motivated by and developed in collaboration with an industrial use-case provider: the Alstom railway company, in the context of the VALU3S European project. In this use-case we formally analyse a motor controller used in signalling systems: a safety-critical embedded system that reacts to instructions to turn a motor left or right.
    • how much was read: only abstract or first pages read
    • source
    • record id: spreadsheet-based-configuration-of
  • The Challenges in Specifying and Explaining Synthesized Implementations of Reactive Systems
    • what: The Challenges in Specifying and Explaining Synthesized Implementations of Reactive Systems∗ Hadas Kress-Gazit Hazem Torfah† Sibley School of Mechanical and Aerospace Engineering Reactive Systems Group Cornell University, Ithaca, NY, USA Saarland University, Saarbrücken, Germany hadaskg@cornell.edu torfah@react.uni-saarland.de In formal synthesis of reactive systems an implementation of a system is automatically constructed from its formal specification. The great advantage of synthesis is that the resulting implementation is correct by construction; therefore there is no need for manual programming and tedious debugging tasks. Developers remain, nevertheless, hesitant to using automatic synthesis tools and still favor manually writing code.
    • how much was read: only abstract or first pages read
    • source
    • record id: the-challenges-in-specifying
  • Validation Obligations: A Novel Approach to Check Compliance between Requirements and their Formal Specification.
    • what: Validation Obligations: A Novel Approach to Check Compliance between Requirements and their Formal Specification 1st Atif Mashkoor 2nd Michael Leuschel 3rd Alexander Egyed Johannes Kepler University Heinrich Heine University Johannes Kepler University Linz, Austria Düsseldorf, Germany Linz, Austria atif.mashkoor@jku.at leuschel@hhu.de alexander.egyed@jku.at arXiv:2102.06037v1 [cs.SE] 11 Feb 2021 Abstract—Traditionally, practitioners use formal methods pre- quality-assurance procedure. While the verification of a for- dominately for one half of the quality-assurance process: verifica- mal specification emphasizes on proving its internal consis- tion (do we build the software right?). The other half – validation tency, validation addresses another important question entirely: (do we build the right software?) – has been given comparatively little attention.
    • how much was read: only abstract or first pages read
    • source
    • record id: validation-obligations-a-novel
  • What causes a system to satisfy a specification?
    • what: Even when a system is proven to be correct with respect to a specification, there is still a question of how complete the specification is, and whether it really covers all the behaviors of the system. Cov- erage metrics attempt to check which parts of a system are actually relevant for the verification process to succeed. Recent work on coverage in model checking suggests several coverage metrics and algo- rithms for finding parts of the system that are not covered by the specification.
    • how much was read: only abstract or first pages read
    • source
    • record id: what-causes-a-system
  • What Challenges Do Developers Face When Using Verification-Aware Programming Languages?
    • what: —Software reliability is critical in ensuring that the Despite their importance, the adoption of VA languages is digital systems we depend on function correctly. In software still low. The reason usually attributed to this is the level of development, increasing software reliability often involves testing.
    • how much was read: only abstract or first pages read
    • source
    • record id: what-challenges-do-developers
  • Isolation levels for free (2026)
    • title: Verifying Isolation Levels of Database Implementations for Free Using Separation Logic
    • what: The paper proves that specs written in separation logic at the implementation level imply transactional consistency models that are defined independently. This holds for all executions of the program.
    • limits: It bridges the meanings of specs. It is not evidence that a new production database is verified.
    • how much was read: reading depth not recorded
    • source; notes: Verifying Isolation Levels of Database Implementations for Free Using
    • record id: isolation-levels-for-free-2026
  • Weak isolation (Aneris) (2025)
    • title: Reasoning about Weak Isolation Levels in Separation Logic
    • what: The paper writes transaction specs that do not depend on the implementation, for read-uncommitted, read-committed and snapshot isolation. It proves that known bad histories are prohibited. It verifies an in-memory, single-node MVCC key-value database, accessed over RPC, in OCaml/Aneris.
    • limits: It covers a single node, with no replication or crash recovery. The review did not verify the translator from source to AnerisLang or the runtime.
    • how much was read: reading depth not recorded
    • source; notes: Reasoning about Weak Isolation Levels in Separation Logic
    • record id: weak-isolation-aneris-2025
  • ADO (2021)
    • title: Much ADO about Failures: A Fault-Aware Model for Compositional Verification of Strongly Consistent Distributed Systems
    • what: The ADO interface shows chosen failure cases to the user. It does not pretend that each operation either fully succeeds or does nothing. The authors use Coq and CCAL to prove that distributed C implementations (for example Multi-Paxos), and the clients built on them, match their abstract specs. The proofs sit on top of the verified CertiKOS.
    • number: multi-Paxos: 2.6K lines of C and 43.9K lines of functional correctness proofs (§6, PDF p.23)
    • limits: The results say nothing about progress (that the system eventually finishes its work). One example assumes termination. That assumption is not a proof of progress.
    • how much was read: reading depth not recorded
    • source; notes: Much ADO about Failures: A Fault-Aware Model for Compositional Verific
    • record id: ado-2021
  • High-Level Specifications: Lessons from Industry (2003)
    • what: An industrial account in which engineers write assertions and inspect counterexamples to understand their own protocol.
    • how much was read: reading depth not recorded
    • source; notes: human specification practice
    • record id: high-level-specifications-lessons-2003
  • From Natural Language to Formal Specifications: A Metamodel-Driven LLM Pipeline (2026)
    • what: Per the input list: an LLM turns free-form natural-language requirements into an intermediate model and then into formal specifications that tools can verify.
    • limits: Full text not read: the ACM page blocked automated download (HTTP 403 from the site’s bot protection, which I did not work around) and no open copy was found. Only the input description and Crossref metadata (authors, venue, 10 pages, Oct 2026) are known; nothing about results.
    • how much was read: not read; title and metadata only
    • source; notes: ## Metamodel-driven LLM pipeline (2026)
    • record id: from-natural-language-to-2026
  • LeanMachines (2026)
    • title: LeanMachines: State-based Modeling with Refinement (a Lean4 Framework)
    • what: A Lean 4 library for modelling stateful systems as machines refined step by step, in the style of Event-B, where a refinement step cannot be built without discharging its proof obligations.
    • limits: Full text not obtained: the journal article had no open PDF; only package-registry and search-result descriptions were read, which call the library alpha-stage and not compatible with Event-B or Rodin. The IFM 2024 predecessor (‘Stateful Functional Modeling with Refinement (a Lean4 Framework)’) was not read.
    • how much was read: not read; title and metadata only
    • notes: ## LeanMachines (2026): metadata only
    • record id: leanmachines-2026
  • Proving liveness with TLA (2026)
    • what: The post proves in TLA+ that Xen vchan data eventually arrives. The first Availability property was vacuously true (it held trivially and said nothing).
    • limits: The review notes read it only through a summarizer.
    • how much was read: not read; title and metadata only
    • source
    • record id: proving-liveness-with-tla-2026
  • AWS correctness practices (2025)
    • title: Systems Correctness Practices at Amazon Web Services
    • what: The paper was not read. Search summaries say it covers P, model checking, fuzzing, property-based testing, fault injection and simulation, with formal specs used as test oracles (the source of expected answers).
    • limits: Fetching the paper returned HTTP 403. The claims are unverified search summaries.
    • how much was read: not read; title and metadata only
    • source; notes: P02. Systems Correctness Practices at Amazon Web Services
    • record id: aws-correctness-practices-2025
  • Investigating the Role of Formal Verification in Software Development: From Automatic Specification Generation to Usability of Verification Languages (2025)
    • what: Per the input list and a search summary of its abstract: a 4-page doctoral plan studying how formal annotations affect code comprehension, how LLMs generate formal specs from code comments, and how usable two verification tools are.
    • limits: Full text not read: the ACM PDF returned HTTP 403 to automated download (bot protection, not worked around) and no open copy was found. Which tools and what results are unknown.
    • how much was read: not read; title and metadata only
    • source; notes: ## Role of formal verification in software development, doctoral paper
    • record id: investigating-the-role-of-2025
  • A Calculus for the Specification, Design, and Verification of Distributed Concurrent Systems (2024)
    • what: Listed as an unread search lead from OpenAlex. The notes give only its title, year and DOI.
    • limits: Not read. Claims are unverified.
    • how much was read: not read; title and metadata only
    • source
    • record id: a-calculus-for-the-2024
  • AWS formal methods video (2024)
    • title: Formal Methods for Distributed Systems
    • what: AWS video metadata describes a re:Invent session introducing P for modeling and verifying complex distributed protocols and discussing formal methods in design and testing.
    • limits: Only the official video page metadata was read; no transcript or slides were retrieved.
    • how much was read: not read; title and metadata only
    • source
    • record id: aws-formal-methods-video-2024
  • Oracle TLA+ talk (2024)
    • title: Reverse-Engineering with TLA+ at Oracle
    • what: The talk covers reverse-engineering TLA+ models at Oracle. The TLA+ Foundation summary says that hundreds of TLA+ specs cover dozens of cloud services.
    • limits: The count comes from the Foundation summary. The review notes did not check it against the video. It is not a proof about Oracle’s codebase. The review notes did not analyze a transcript.
    • how much was read: not read; title and metadata only
    • source; notes: R08. Oracle and Intel: scope of the public evidence
    • record id: oracle-tla-talk-2024
  • Oracle TLA+ talk (2021)
    • title: Reverse Engineering with TLA+
    • what: YouTube metadata identifies a TLA+ Foundation recording titled “Reverse Engineering with TLA+ — Calvin Loncaric, Oracle”.
    • limits: Only metadata retrieved; not transcribed.
    • how much was read: not read; title and metadata only
    • source
    • record id: oracle-tla-talk-2021
  • Gleirscher and Marmsoler survey of professionals (2020)
    • what: Survey of professionals on formal methods adoption.
    • number: N=216
    • limits: Used only for the barriers to adoption: scalability, skills and education.
    • how much was read: not read; title and metadata only
    • record id: gleirscher-and-marmsoler-survey-2020
  • Practical TLA+ (2018)
    • what: Citation-snowball lead; full text was not retrieved from the attempted open endpoints.
    • limits: Metadata-only: attempted open endpoints returned access-denied or non-PDF HTML; the paper was not read.
    • how much was read: not read; title and metadata only
    • source
    • record id: practical-tla-2018
  • Consistency Checking in Requirements Analysis (title the input gave: Online enumeration of minimal inconsistent subsets of temporal requirements) (2017)
    • what: A doctoral-symposium proposal: a framework to list every minimal inconsistent subset (a smallest group of requirements that cannot all hold together) of requirements written in temporal logic such as LTL, one at a time.
    • limits: Full text not obtained: the ACM page returned no PDF and no open copy was found (the arXiv paper 1708.00400 is a different, later paper). Only the title and abstract-level description from a web search were seen; record is metadata only. Input file title does not match what the DOI resolves to.
    • how much was read: not read; title and metadata only
    • source; notes: ## Online enumeration of minimal inconsistent subsets of temporal requ
    • record id: consistency-checking-in-requirements-2017
  • Thread modularity at many levels: a pearl in compositional verification (2017)
    • what: Citation-snowball lead; full text was not retrieved from the attempted open endpoints.
    • limits: Metadata-only: attempted open endpoints returned access-denied or non-PDF HTML; the paper was not read.
    • how much was read: not read; title and metadata only
    • source
    • record id: thread-modularity-at-many-2017
  • Auth Invariant Tester: Temporal Authorization Correctness Verification for Distributed Systems
    • what: Per the input list, a tester for whether distributed authorization (caching, delayed revocation, token lifetime) keeps temporal correctness properties; not read.
    • limits: Full text could not be fetched: the Authorea page and DOI link return a Cloudflare ‘Just a moment’ challenge, which I did not work around. Everything here comes from the one-line description in the input file.
    • how much was read: not read; title and metadata only
    • source; notes: ## Auth Invariant Tester (metadata only)
    • record id: auth-invariant-tester-temporal
  • Proving Possibility Properties
    • what: The paper proves possibility properties (something can happen) as sanity checks on a spec.
    • limits: The notes did not read the paper itself. They know it from the author’s page.
    • how much was read: not read; title and metadata only
    • record id: proving-possibility-properties

Last edited: