Pacheck 2.0: Algebraic Proof Recycling

• Pacheck 2.0 is an algebraic proof checker for LPAC that verifies polynomial ideal membership under Boolean constraints.
• It introduces two novel rules, PatternNew and PatternApply, to recycle recurring proof fragments and reduce verification steps.
• Benchmarks show that the pattern mechanism significantly reduces proof steps, file size, and runtime in arithmetic circuit verification.

Searching arXiv for the specified paper and closely related prior work on PAC/LPAC and Pacheck. Pacheck 2.0 is an algebraic proof checker for the Practical Algebraic Calculus with linear combinations (LPAC), extended with two “recycling” rules, PatternNew and PatternApply, that permit capture and reuse of recurring proof fragments. It verifies algebraic proof certificates showing that a target polynomial $f$ belongs to the ideal generated by a set of axioms $G \subseteq K[X]$, with particular emphasis on Boolean variables modeled by the axioms $B(X)=\{x^2-x \mid x \in X\}$ (Kaufmann et al., 27 Jul 2025). The system is situated in the proof-logging and proof-checking tradition familiar from SAT and QBF, but specialized to algebraic derivations, especially those arising in arithmetic circuit verification. Its central contribution is the condensation of certificates by factoring repeated derivations into patterns that are checked once and later instantiated under suitable substitutions, thereby reducing proof size and verification time (Kaufmann et al., 27 Jul 2025).

1. Formal setting and verification objective

Pacheck takes as input a field $K$, a set of variables $X$, a set of polynomials $G \subseteq K[X]$, a target polynomial $f \in K[X]$, and an LPAC proof certificate intended to establish

$f \in \langle G \rangle.$

In the Boolean setting, for each $x \in X$, the polynomial $x^2-x$ is added to the axioms, so Booleanity is represented by the ideal generated by $G \subseteq K[X]$0 (Kaufmann et al., 27 Jul 2025).

An LPAC proof is a sequence of states. In the original formulation, the state is $G \subseteq K[X]$1, where $G \subseteq K[X]$2 is the current variable set and $G \subseteq K[X]$3 is a sequence indexed by integers, with each $G \subseteq K[X]$4 either a polynomial in $G \subseteq K[X]$5 or “undefined” $G \subseteq K[X]$6. Initially, $G \subseteq K[X]$7. In the extended system implemented by Pacheck 2.0, the state becomes $G \subseteq K[X]$8, where $G \subseteq K[X]$9 is a sequence of reusable patterns. Initially, $B(X)=\{x^2-x \mid x \in X\}$0, and the legacy rules do not modify it (Kaufmann et al., 27 Jul 2025).

The checker parses each proof step, checks syntactic and semantic side conditions, recomputes algebraic operations, and verifies the claimed conclusion polynomial. For LinComb, it explicitly computes the linear combination and reduces modulo $B(X)=\{x^2-x \mid x \in X\}$1, then compares the result with the declared polynomial. Acceptance occurs when the target polynomial $B(X)=\{x^2-x \mid x \in X\}$2 is derived and all prior steps are valid; otherwise the checker reports the first failed check (Kaufmann et al., 27 Jul 2025).

This verification model places Pacheck 2.0 between two familiar algebraic proof paradigms. Polynomial Calculus supports derivations via ideal-theoretic algebraic rules, whereas Nullstellensatz-style certificates use explicit linear combinations. LPAC combines PC-style derivability with an NSS-like linear-combination layer while retaining local checkability and error localization, and Pacheck is the corresponding checker for that calculus (Kaufmann et al., 27 Jul 2025). This suggests that the design objective is not only proof existence but operational certification under machine-checkable local conditions.

2. LPAC rules and proof-state semantics

The core LPAC rules implemented by earlier Pacheck versions and retained in Pacheck 2.0 are Axiom, Deletion, LinComb, and Ext (Kaufmann et al., 27 Jul 2025).

The Axiom rule inserts a polynomial $B(X)=\{x^2-x \mid x \in X\}$3 at an undefined index $B(X)=\{x^2-x \mid x \in X\}$4 and enlarges the current variable set with the variables occurring in $B(X)=\{x^2-x \mid x \in X\}$5: $B(X)=\{x^2-x \mid x \in X\}$6

The Deletion rule sets $B(X)=\{x^2-x \mid x \in X\}$7 to $B(X)=\{x^2-x \mid x \in X\}$8: $B(X)=\{x^2-x \mid x \in X\}$9 Its role is operational rather than deductive, since it reduces the memory footprint during checking (Kaufmann et al., 27 Jul 2025).

The LinComb rule is the central algebraic inference mechanism. It derives a polynomial $K$0 as a linear combination of existing polynomials modulo the Boolean ideal: $K$1

$K$2

The side condition expresses equality modulo $K$3, which is the algebraic representation of Boolean semantics in the system (Kaufmann et al., 27 Jul 2025).

The Ext rule introduces a new Boolean variable $K$4 as an alias for a Boolean expression $K$5: $K$6 The proof object stores the equation as $K$7, thereby enforcing $K$8, and the condition $K$9 ensures that the introduced alias is Boolean modulo the Boolean axioms (Kaufmann et al., 27 Jul 2025).

These rules define LPAC as a practical system for machine-verifiable ideal-membership derivations. Pacheck 2.0 preserves this operational core and adds a mechanism for explicitly factoring repeated subderivations.

3. Pattern-based proof recycling

The distinctive extension in Pacheck 2.0 is the addition of PatternNew and PatternApply, which implement proof recycling by storing and reusing verified proof fragments (Kaufmann et al., 27 Jul 2025).

A pattern stored at index $X$0 consists of a sequence of input polynomials $X$1, a sequence of internal LPAC proof steps $X$2, a set of selected output polynomials $X$3, and the set $X$4 of extension variables occurring in $X$5. The rule

$X$6

checks that $X$7 forms a correct standalone LPAC proof and then stores only the summary $X$8 in the pattern table $X$9, discarding the internal derivation $G \subseteq K[X]$0 afterward (Kaufmann et al., 27 Jul 2025). Formally,

$G \subseteq K[X]$1

The companion rule PatternApply instantiates a stored pattern using a substitution $G \subseteq K[X]$2, a set $G \subseteq K[X]$3 of fresh extension variables for the current application, indices of existing input polynomials, and designated output locations: $G \subseteq K[X]$4 Its side conditions require that the pattern exists, the extension variables are fresh, extension variables from the stored pattern are mapped injectively to variables in $G \subseteq K[X]$5, every variable image under $G \subseteq K[X]$6 is Boolean modulo $G \subseteq K[X]$7, the instantiated pattern inputs match the currently stored polynomials $G \subseteq K[X]$8, and the instantiated outputs match the declared $G \subseteq K[X]$9 (Kaufmann et al., 27 Jul 2025). The resulting state is

$f \in K[X]$0

The semantic intuition is that PatternNew validates a local LPAC derivation once, while PatternApply reuses the corresponding input-output relation without replaying the internal steps. The paper characterizes this as “recycling” algebraic proof fragments, especially when the same proof steps recur for different variable sets (Kaufmann et al., 27 Jul 2025). A plausible implication is that the pattern mechanism introduces a proof-engineering layer over LPAC, separating local derivational correctness from repeated deployment across isomorphic contexts.

4. Illustrative derivations and proof structure

The paper gives two representative examples. The first reuses a linear-combination pattern. With

$f \in K[X]$1

the goal is to prove $f \in K[X]$2. A pattern is defined with inputs $f \in K[X]$3 and $f \in K[X]$4, one internal LinComb step deriving $f \in K[X]$5, and output $f \in K[X]$6. It is then instantiated twice, first with

$f \in K[X]$7

yielding $f \in K[X]$8, and again with

$f \in K[X]$9

yielding $f \in \langle G \rangle.$0. A final LinComb step combines these with $f \in \langle G \rangle.$1 to derive $f \in \langle G \rangle.$2 (Kaufmann et al., 27 Jul 2025). The example isolates the precise redundancy targeted by the system: a linear combination computed once in a pattern and then reused at multiple instantiations.

The second example shows that patterns may include extension-variable reasoning. From the polynomials encoding $f \in \langle G \rangle.$3 and $f \in \langle G \rangle.$4,

$f \in \langle G \rangle.$5

the proof introduces a new variable $f \in \langle G \rangle.$6 for $f \in \langle G \rangle.$7 and derives $f \in \langle G \rangle.$8. The pattern contains both an Ext step introducing $f \in \langle G \rangle.$9 as $x \in X$0 and a LinComb step deriving $x \in X$1. Instantiation with

$x \in X$2

produces the relation $x \in X$3 and the resolvent polynomial $x \in X$4 (Kaufmann et al., 27 Jul 2025). This demonstrates that proof recycling is not limited to repeated coefficient patterns in linear combinations; it also covers recurring extension-variable constructions.

These examples are significant because they make the granularity of the abstraction explicit. The reusable object is neither a macro over syntax alone nor a global lemma in an external meta-language; it is a checked LPAC fragment with declared inputs and outputs, instantiated under substitutions that satisfy the same Boolean side conditions as ordinary LPAC steps.

5. Checker architecture and operational consequences

Pacheck 2.0 reads proof commands from the set Axiom, Deletion, LinComb, Ext, PatternNew, and PatternApply, and maintains the state $x \in X$5, where $x \in X$6 contains current variables including Boolean extension variables, $x \in X$7 is the polynomial array, and $x \in X$8 is the pattern table whose entries store $x \in X$9 (Kaufmann et al., 27 Jul 2025).

Processing PatternNew(i,I,S,O) requires three checks: that $x^2-x$0, that Correct-LPAC-Proof(I,S) holds by running the standard LPAC verifier on the local proof fragment $x^2-x$1, and that every output in $x^2-x$2 occurs among the conclusions of $x^2-x$3. The checker then computes $x^2-x$4, stores $x^2-x$5 at $x^2-x$6, and discards $x^2-x$7 (Kaufmann et al., 27 Jul 2025). The discarding of internal steps is operationally important because it allows the persistent certificate state to retain only the summary needed for later applications.

Processing PatternApply requires verifying pattern existence, freshness of the supplied extension variables, injective mapping of stored extension variables into fresh variables, Boolean consistency of every variable image under $x^2-x$8, matching of instantiated inputs against already-defined polynomials, and matching of instantiated outputs against the newly declared result polynomials (Kaufmann et al., 27 Jul 2025). If these checks succeed, the checker extends the state by the fresh variables and stores the instantiated outputs at the designated indices.

The paper contrasts the operational cost of repeated derivations with and without patterns. Without patterns, repeated subderivations must be replayed as multiple LinComb or Ext steps, each of which triggers algebraic verification. With patterns, the internal derivation is checked once in PatternNew, and each later application performs structural and substitution checks instead of full replay (Kaufmann et al., 27 Jul 2025). The paper does not derive formal complexity bounds, but explicitly states that experimentally the pattern mechanism reduces both the number of steps to check and the overall runtime (Kaufmann et al., 27 Jul 2025).

This suggests a modularization of proof checking analogous to memoization at the certificate level. The stored object is not a cached arithmetic result but a certified derivational schema.

6. Benchmark evaluation

The implementation was evaluated on multiplier-verification benchmarks, where the task is to prove that a circuit specification polynomial belongs to the ideal generated by circuit-encoding polynomials. This benchmark family is particularly suitable because multipliers contain repeated substructures such as adders, so proof recycling can exploit isomorphic reasoning patterns (Kaufmann et al., 27 Jul 2025).

The reported benchmark set includes abc, abc-rsn, and abc-cmp with 64 axioms, and sp-ar-rc, sp-bd-rc, sp-dt-rc, sp-os-rc, and sp-ar-cl with 96–108 axioms (Kaufmann et al., 27 Jul 2025). The comparison distinguishes LPAC without patterns from LPAC with patterns. For the baseline, the metrics are number of LinComb steps (“Steps”, $x^2-x$9), proof file size (“File” in MB), memory usage (“Mem” in MB), and verification time (“Time” in seconds). For the extended system, the metrics additionally include the number of PatternNew commands (“#”), the number of PatternApply commands (“Apply”), and the maximum number of internal steps per pattern $G \subseteq K[X]$00 (Kaufmann et al., 27 Jul 2025).

Benchmark	Without patterns	With patterns
abc	196k steps, 454 MB file, 982 MB memory, 10.17 s	48k steps, 9 PatternNew, 4032 PatternApply, max pattern length 46, 439 MB file, 913 MB memory, 9.61 s
sp-bd-rc	284k steps, 1130 MB file, 2098 MB memory, 32.33 s	111k steps, 42 PatternNew, 6520 PatternApply, max pattern length 87, 1117 MB file, 2038 MB memory, 29.45 s
sp-ar-cl	2043k steps, 959 MB file, 1867 MB memory, 25.98 s	1820k steps, 79 PatternNew, 3999 PatternApply, max pattern length 421, 924 MB file, 1749 MB memory, 24.37 s

Across all benchmarks, the pattern extension significantly reduces the number of proof steps, reliably reduces proof file size, and usually reduces memory usage and verification time; no benchmark worsened under the pattern-based system in these metrics (Kaufmann et al., 27 Jul 2025).

The empirical profile is notable because the largest improvement is in step count, while file-size improvements are smaller in absolute terms for some instances. This suggests that the dominant effect is elimination of repeated derivational replay, with secondary gains in certificate size and checking resources.

7. Soundness, scope, and relation to algebraic proof certification

The soundness discussion proceeds by inheritance from LPAC. The original rules Axiom, Deletion, LinComb, and Ext preserve the invariant that all polynomials in $G \subseteq K[X]$01 lie in the ideal generated by the axioms together with $G \subseteq K[X]$02. PatternNew is sound because it requires Correct-LPAC-Proof(I,S) and merely stores a summary without changing the current polynomial state. PatternApply is sound because it instantiates a sound LPAC derivation under a mapping $G \subseteq K[X]$03 that preserves Boolean consistency, matches actual inputs, and maps extension variables to fresh Booleans (Kaufmann et al., 27 Jul 2025). Detailed formal proofs are not given in the excerpt, but the rule design is explicitly intended to inherit soundness from the underlying LPAC calculus (Kaufmann et al., 27 Jul 2025).

The mechanism is instantiated for LPAC with Boolean variables. This matters because LinComb is defined modulo $G \subseteq K[X]$04, Ext requires Booleanity of the alias expression, and PatternApply requires

$G \subseteq K[X]$05

for every variable $G \subseteq K[X]$06 appearing in the pattern (Kaufmann et al., 27 Jul 2025). In non-Boolean settings, the mapping constraints would have to be adjusted accordingly. The paper states that extending the idea of patterns to other polynomial proof systems is conceptually straightforward but requires dedicated instantiation of the mapping constraints (Kaufmann et al., 27 Jul 2025).

Within the broader algebraic-certification landscape, Pacheck 2.0 addresses the practical problem that proof certificates often contain the same proof steps repeated for different variable sets. The pattern store $G \subseteq K[X]$07, together with PatternNew and PatternApply, is the formal mechanism by which these repetitions are factored out (Kaufmann et al., 27 Jul 2025). This is especially relevant in arithmetic circuit verification, where repeated reasoning over isomorphic subcircuits such as full or half adders can be replaced by a single stored pattern and many applications (Kaufmann et al., 27 Jul 2025).

The paper also identifies open directions, including combining pattern-based recycling with new methods for finding short ideal-membership proofs, cited there as [HV24], and pursuing further efficiency improvements in proof checking (Kaufmann et al., 27 Jul 2025). A plausible implication is that the long-term significance of Pacheck 2.0 lies not only in certificate compression, but in the emergence of reusable proof schemata as first-class objects within algebraic proof logging.