Skip to content

Adopt ordeal for certificate-checked optimization-rule verification (replace loom's own Z3 path) #277

Description

@avrabe

Field report from ordeal (certificate-checked QF_BV engine). Not a bug in loom — an adoption opportunity surfaced while wiring ordeal's v0.7.0 consumer surface.

What I observed (origin/main)

loom-core verifies its optimization rules with Z3 directly, behind the verification = ["z3"] feature (verify_rules / examples/verify_rules_demo.rs"uses Z3 to PROVE optimization rules are correct"). The Z3 Unsat verdict ("rule holds for all inputs") is trusted with no independent certificate, and the build pulls in a Z3 link dependency (the real pain called out in #246).

The opportunity

Rule verification here is QF_BV equivalence (bitvector op ≡ op, widths 8/32/64) — squarely inside ordeal's closed fragment. Two moves, both already precedented in the org:

  1. Swap the engine. ordeal::Solver::prove_equiv(a, b) is the one-call equivalence-as-UNSAT primitive; Unsat = "equal for every input". Pure-Rust, zero-dep default build, builds on wasm32-wasip2 — no static-link-z3. This is exactly what synth-verify did (synth#553, completed: ordeal default, Z3 demoted to optional differential oracle).
  2. Get a certificate you can re-check. As of ordeal v0.7.0 the Unsat Certificate carries both the refuted CNF (cert.cnf) and the LRAT proof (cert.lrat), and cert.recheck() re-validates the pair through the formally-verified ordeal-lrat checker. So "these rules are equivalent" becomes evidence loom can reproduce, not solver faith — the certifying-validator direction (cf. synth#667).

Scope / honesty

  • Not urgent and not a soundness bug: Z3 is sound in practice. The value is (a) a checkable certificate instead of trust, and (b) dropping the Z3 build/link burden.
  • If any rule uses a construct outside the closed fragment (quantifiers, FP, non-consecutive symbolic array indices), ordeal returns Unknown (conservative) — tell us the exact term and it becomes a missing-capability on ordeal.

Refs

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions