Subgoal Cache for Parallel Proof Search

• The paper presents a subgoal cache mechanism that significantly reduces redundant proof state reconstructions across parallel search branches.
• It details two implementation strategies—Lean 4’s snapshotting and BFS-Prover-V2’s shared hash map—that streamline proof search pipelines.
• Empirical results show up to 30× speedup and over 99% overhead reduction, enabling scalable, portfolio-based tactic search.

A subgoal cache for parallel proof search is a mechanism that enables efficient reuse of intermediate proof states and subgoal results among multiple branches or agents searching for proofs in parallel. In contemporary automated theorem proving systems built on proof assistants such as Lean 4 and LLM-based planners, subgoal caches address the substantial overhead caused by redundant proof state reconstruction and redundant work across concurrent proof search agents. These caches can take the form of proof-state snapshot storage, as in Lean 4’s snapshotting approach (Shen et al., 25 May 2026), or shared subgoal-to-proof-term hashes in hierarchical multi-agent planners such as BFS-Prover-V2 (Xin et al., 8 Sep 2025). Both approaches enable scalable, parallel, and portfolio-based tactic search by drastically reducing recomputation.

1. Motivation and Problem Statement

Parallel proof search, especially in the context of Draft-Sketch-Prove (DSP) pipelines and multi-agent tree search, typically entails significant per-branch overhead. In systems such as Lean 4, each search branch traditionally reconstructs the entire proof state by repetitively re-elaborating the theorem (import loading and theorem-body elaboration). For Lean 4 with Mathlib, this incurs import loading times of approximately 60 seconds per branch and theorem-body elaboration delays of 18–735 seconds per branch, often constituting over 99% of total per-branch wall time (Shen et al., 25 May 2026). In planner-based multi-agent provers, the absence of cache mechanisms for subgoal results leads to redundant searches when distinct agents independently attempt to solve identical subgoals (Xin et al., 8 Sep 2025). Thus, the inefficiency stems from a mismatch: proof search branches fork at the logical level but reconstruct the computational state from scratch.

2. Data Structures and Algorithms

Snapshots in Lean 4

Lean 4’s subgoal cache is realized through proof-state snapshotting. The server maintains, for each open file, a FileWorker which constructs a chain of Snapshot objects during elaboration. Each Snapshot encodes:

• An immutable Environment containing all loaded constants and type-class instances (~2–4 GB)
• The current MetavarContext (mutable, ~KB) tracking open metavariable assignments
• The current LocalContext (local hypotheses and bindings) (Shen et al., 25 May 2026)

Three JSON-RPC primitives support snapshot operations:

1. $$/lean/dspSnapshotPing</code> checks server snapshot support.</li> <li><code>$$/lean/dspSnapshotCapture(uri, position) records a snapshot at a specific source location (typically a sorry-hole).
2. $$/lean/dspSnapshotBranch</code>(snapshotId, [tactic, ...]) forks the captured state by copying only the lightweight <code>MetavarContext</code> and shares the Environment by reference; the requested tactics are run in parallel on the cloned states.</li> </ol> <p>The forking operation cost is$$O(|\text{MetavarContext}|)$$, avoiding redundant import loading and theorem elaboration per branch.</p> <h3 class='paper-heading' id='shared-subgoal-cache-in-bfs-prover-v2'>Shared Subgoal Cache in BFS-Prover-V2</h3> <p>BFS-Prover-V2’s subgoal cache is a concurrent hash map:</p> <ul> <li>Key: <code>SubgoalKey = hash(normalize(q))</code> where$$q$$is a Lean proposition normalized via alpha-renaming and canonical serialization.</li> <li>Value: <code>CacheEntry = { status ∈ {PENDING, PROVING, PROVEN}, proofTree, proofTerm, version }</code> with fine-grained concurrency control.</li> <li>Lookup retrieves proven proof terms if valid for the current planner version; insertion occurs after an agent finds a proof.</li> <li>Entries are versioned to handle <a href="https://www.emergentmind.com/topics/dynamic-planner" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">dynamic planner</a> replanning (invalidating or evicting stale subgoals).</li> </ul> <p>$$q$6 Concurrent access is managed by locking individual buckets or using a lock-free hash map, and atomic compare-and-swap ensures only one agent declares a subgoal as PROVEN. On cache hits, proof terms are type-checked and immediately reused; otherwise, parallel agents race to resolve and populate the cache (Xin et al., 8 Sep 2025).

   3. Theoretical Cost Models and Speedup

   Lean 4’s Snapshotting

   Let $H$= number of sorry holes,$C$= tactic portfolio size,$n = H \times C$,$T_\mathrm{load}$= import time,$T_\mathrm{body}$= theorem-body elaboration time, and$T_\mathrm{tactic}$$= average tactic runtime.</p> <p><strong>Naive fallback (no cache):</strong></p> <p>$$T_\mathrm{fallback}(H, C) = n \left(T_\mathrm{load} + T_\mathrm{body}\right)$$</p> <p><strong>Snapshot-based search:</strong></p> <p>$$T_\mathrm{native}(H, C) = T_\mathrm{load} + T_\mathrm{body} + n T_\mathrm{tactic}$$</p> <p><strong>Asymptotic speedup:</strong></p> <p>$$q$0

   where $q$1 and $q$2. Thus, speedup is roughly linear in the number of branches $q$3 until hardware bottlenecks arise (Shen et al., 25 May 2026).

   BFS-Prover-V2

   The cache enables avoidance of repeated search for recurrent subgoals. Empirically, cache hit rates of 40–50% and overall wall-clock speedup of approximately 30–60% are reported, with parallel agents maximizing effective throughput (Xin et al., 8 Sep 2025).

   4. Implementation Strategies

   Lean 4 Snapshotting

   Implementation consists of a minimal patch (~<200 LOC) to Lean.Server.FileWorker:

   • Registers RPC handlers at startup
   • The client orchestrator identifies sorry-holes in the proof sketch, captures snapshot IDs, batches tactic trials per hole using dspSnapshotBranch, and collects results.

   The mechanism is orthogonal to pre-existing import-level caching (as in Kimina Lean Server): import-level caches avoid only import loading per branch, but do not circumvent theorem elaboration overhead (Shen et al., 25 May 2026).

   BFS-Prover-V2

   Each subgoal is registered in the shared subgoal cache with status=PENDING upon planner decomposition. Parallel prover agents consult the cache before commencing search; on misses, they perform best-first search and atomically insert successful proofs. Agents abort duplicate subgoal search upon cache update. Dynamic replanning increments a global cache version, evicting all old entries.

   5. Empirical Performance and Scaling

   Lean 4 Snapshotting

   Benchmarks on 48 miniF2F-v2 problems (MacBook Pro M-series, 8 GB RAM) demonstrate:

   • Full DSP pipeline: 5.6–50× wall-time speedup (mean 14×, median 9.7×).
   • For H=5 holes (35 branches): 132.8 s native vs 2641.4 s fallback (≈19.9×)
   • Per-branch overhead reduction >99.9%; actual tactic execution is negligible compared to startup cost.

   Representative results:

   Theorem	Holes $q$4	Native (s)	Fallback (s)	Speedup
   mathd_nt_345	5	132.8	2641.4	19.9×
   mathd_alg_478	4	119.9	1579.6	13.2×
   Prove-only $q$5	5	141	4436	29.8×

   Speedup scales quasi-linearly with number of parallel branches, limited by available CPU and memory (Shen et al., 25 May 2026).

   BFS-Prover-V2

   With subgoal caching and hierarchical planning, BFS-Prover-V2 increases MiniF2F pass rate from 86.1% (monolithic) to 95.1% (with planner + subgoal cache). Anecdotal evidence indicates ≈2× runtime improvement per theorem on ProofNet, with overall cache hit rates of 40–50%. The subgoal cache supports up to 8 concurrent agents efficiently (Xin et al., 8 Sep 2025).

   6. Interactions, Limitations, and Comparison

   Subgoal caches are generally orthogonal and complementary to other caching and parallelism layers:

   • Lean’s SavedState is intra-branch backtracking; snapshotting is for inter-branch forking.
   • Parallel compilation and white-box state factorization (e.g., Pantograph, LeanTree) are unrelated to branch-for-branch startup cost.
   • For Lean 4, combining both import-level and snapshot caching is projected to yield >100× speedups for large portfolios (Shen et al., 25 May 2026).

   Key limitations include:

   • Both mechanisms require patched binaries or orchestrators (Lean’s patched LSP, BFS-Prover-V2’s cache management).
   • The caches do not enhance proof accuracy or search quality—acceleration derives solely from elimination of redundant computation.
   • Hardware scaling limits for larger agent counts or environments exceeding RAM are unquantified in the present evaluations.

   In summary, subgoal caching—either through proof-state snapshots or shared concurrent subgoal caches—transforms the cost structure of parallel proof search by elevating reuse of intermediate states and results. It enables portfolio-based and multi-agent techniques to scale effectively, moving bottlenecks from startup overhead to actual tactic evaluation or proof construction (Shen et al., 25 May 2026, Xin et al., 8 Sep 2025).