The ONE Variable: How a Missing Initialization Caused a Crash in GPU-Accelerated Zero-Knowledge Proving

The Message

In an opencode coding session focused on extending Pre-Compiled Constraint Evaluator (PCE) extraction to all proof types in the CuZK proving engine, the assistant produced the following analysis (message 140 of the conversation):

new() calls new_empty() which sets num_inputs = 0. Then synthesize_extendable calls cs.alloc_input("temp ONE", ...) which bumps num_inputs to 1 and returns Variable(Input(0)). That's the child's first input. But wait — there's no built-in ONE! In WitnessCS::new(), the constructor pre-allocates input_assignment = vec![Scalar::ONE], making index 0 the ONE variable. But RecordingCS::new() starts empty.

So in a child RecordingCS: - new() → num_inputs = 0 - alloc_input("temp ONE") → num_inputs = 1, returns Input(0)

But in a child WitnessCS: - new() → input_assignment = [ONE], so len = 1 - alloc_input("temp ONE") → pushes, len = 2, returns Input(1)

This means the child RecordingCS and child WitnessCS have different input indexing! The child RecordingCS has "temp ONE" at input index 0, while WitnessCS has "temp ONE" at input index 1 (with built-in ONE at index 0).

For WitnessCS::extend, it skips other.input_assignment[0] (the built-in ONE). The "temp ONE" at index 1 gets appended as a regular input.

For my RecordingCS::extend, I'm skipping other.num_inputs - 1... but the child's input 0 IS the "temp ONE", not a built-in ONE. There is no built-in ONE in the child RecordingCS.

This is a fundamental mismatch. RecordingCS::new() doesn't pre-allocate a ONE variable, but WitnessCS::new() does. I need to make RecordingCS::new() also pre-allocate a ONE input to match.

This message is the critical turning point in a debugging session that began with a mysterious crash: the witness produced 26036 inputs while the Pre-Compiled Constraint Evaluator (PCE) expected only 25840. The difference of 196 inputs was not random — it exactly matched the number of parallel synthesis chunks configured for WindowPoSt proving. What follows is a deep exploration of how a single boolean flag — is_extensible() — and a subtle initialization mismatch conspired to break GPU-resident zero-knowledge proving for an entire proof type.

Context: The CuZK Proving Engine and PCE Extraction

To understand this message, one must first understand the architecture of the CuZK proving engine. CuZK is a high-performance GPU-accelerated zero-knowledge proving system for Filecoin proof types. At its heart lies the Pre-Compiled Constraint Evaluator (PCE), a technique that separates circuit topology extraction from witness generation. Instead of re-synthesizing the entire R1CS constraint system for every proof — an expensive operation involving millions of constraint allocations — CuZK performs synthesis once per circuit type, recording the fixed constraint structure into a PreCompiledCircuit data structure. This structure is serialized to disk and reused for all subsequent proofs of the same type. The GPU then evaluates constraints directly from this pre-compiled representation, dramatically reducing proving time.

The system uses two different constraint system implementations for different phases. RecordingCS is used during PCE extraction: it faithfully records every constraint, variable allocation, and linear combination into CSR (Compressed Sparse Row) matrix form. WitnessCS is used during fast proving: it only tracks witness assignments (input and auxiliary variable values) without recording constraint structure, since the structure is already captured in the PCE.

Both implement the ConstraintSystem trait from the bellpepper-core library. This trait defines the interface for R1CS synthesis, including methods like alloc_input, alloc, enforce, and crucially, is_extensible() and extend().

The Crash: When PCE and Witness Disagree

The session began with a successful implementation of PCE extraction for WinningPoSt, WindowPoSt, and SnapDeals proof types. The assistant had extended the existing PoRep-only extraction pipeline, added a partitioned pipeline for SnapDeals to overlap synthesis with GPU proving, and wired everything together in the engine. The changes compiled cleanly and were deployed for testing.

Then came the crash. When the user tested WindowPoSt with PCE enabled, the GPU evaluator hit a fatal assertion: the witness had 26036 inputs while the PCE expected 25840. The assistant's first hypothesis — that the circuit dimensions varied with sector count — was quickly dismissed by the user, who correctly noted that "r1cs can't just morph shape so inputs have to be the same." The circuit structure is fixed for a given registered proof type; WINDOW_POST_SECTOR_COUNT for 32 GiB is a constant 2349 sectors, and the challenge count is always 10. The PCE's count of 25840 was the correct baseline.

The difference was exactly 196 inputs. This number, as the assistant would later discover, matched SETTINGS.window_post_synthesis_num_cpus — the number of parallel chunks used during WindowPoSt synthesis.

The Investigation: Tracing the Root Cause

The assistant's investigation followed a methodical chain of evidence. First, it confirmed that WitnessCS::is_extensible() returns true (line 120-122 of witness_cs.rs), while RecordingCS did not implement is_extensible() at all, inheriting the trait default of false (line 134-136 of constraint_system.rs). This single boolean difference caused the FallbackPoStCircuit to dispatch to completely different synthesis paths.

The synthesize_extendable path (lines 211-240 of storage-proofs-post-19.0.1/src/fallback/circuit.rs) splits sectors into num_chunks parallel groups. Each chunk creates a new constraint system via CS::new(), then allocates a "temp ONE" input via cs.alloc_input(|| "temp ONE", || Ok(Fr::ONE)). After synthesis, each chunk's CS is merged into the parent via extend(). The WitnessCS::extend() method skips the first input (index 0, the built-in ONE) but includes the "temp ONE" at index 1. This means each parallel chunk adds exactly one extra public input to the final system — the "temp ONE" that becomes a real input after extension.

The synthesize_default path, by contrast, runs sequentially with no chunking and no extra inputs. Since RecordingCS returned is_extensible() = false, it took the default path and produced exactly the correct number of inputs (25840). WitnessCS returned is_extensible() = true, took the extensible path, and produced 25840 + 196 = 26036 inputs.

The assistant correctly identified the fix: make RecordingCS extensible so it takes the same synthesize_extendable path as WitnessCS. This required implementing is_extensible() (returning true), extend() (with proper CSR column index remapping), and ensuring the constructor initializes identically.

The Deeper Bug: The Missing ONE

The target message captures the moment the assistant realized that implementing extend() was not sufficient. There was a second, subtler mismatch lurking in the constructors.

In R1CS constraint systems, the variable at input index 0 is conventionally reserved as a constant "ONE" — a variable whose value is always the multiplicative identity of the field. Circuits reference this variable to represent constant values in linear combinations. WitnessCS::new() faithfully pre-allocates this ONE variable by setting input_assignment = vec![Scalar::ONE], giving it length 1. When synthesize_extendable then calls cs.alloc_input(|| "temp ONE", || Ok(Fr::ONE)), the "temp ONE" lands at index 1.

But RecordingCS::new() called new_empty(), which set num_inputs = 0 and allocated no variables. When synthesize_extendable called cs.alloc_input(|| "temp ONE", || Ok(Fr::ONE)), the "temp ONE" landed at index 0 — there was no built-in ONE to skip. The child RecordingCS had its "temp ONE" at index 0, while the child WitnessCS had its "temp ONE" at index 1.

This meant the extend() logic the assistant had just written was fundamentally wrong. The WitnessCS::extend() skips other.input_assignment[0] (the built-in ONE) and appends everything from index 1 onward (including the "temp ONE"). The assistant's RecordingCS::extend() was attempting to skip other.num_inputs - 1 inputs, but in a child RecordingCS, input 0 was the "temp ONE" — there was no built-in ONE to skip. The extend logic would either skip the wrong variable or include the wrong variable, depending on how the remapping was written.

The assistant's realization is captured in the message's closing insight: "This is a fundamental mismatch. RecordingCS::new() doesn't pre-allocate a ONE variable, but WitnessCS::new() does. I need to make RecordingCS::new() also pre-allocate a ONE input to match."

The Fix and Its Ripple Effects

The fix involved three coordinated changes to RecordingCS:

Pre-allocate ONE in new(): Change the constructor to set num_inputs = 1 and record the ONE variable's presence, matching WitnessCS::new().
Implement extend() with correct remapping: The extend method must skip the child's input 0 (the built-in ONE), remap child input indices by subtracting 1 (to skip ONE) and adding the parent's current input count, and remap child auxiliary indices by adding the parent's current auxiliary count. The CSR column encoding uses an AUX_FLAG bit to distinguish input columns from auxiliary columns, so the remapping must preserve this encoding.
Update extract_precompiled_circuit(): The extraction function previously called cs.alloc_input(|| "one", || Ok(Scalar::ONE)) to manually allocate the ONE variable. With new() now pre-allocating ONE, this manual allocation would double-count the ONE, pushing num_inputs to 2 instead of 1. The fix was to remove the manual alloc_input call. The assistant recognized this ripple effect immediately after the target message, noting: "But wait — this changes the behavior of the main extraction path too. [...] If new() now sets num_inputs = 1, then alloc_input makes it 2. That's wrong for the main path." The solution was to update extract_precompiled_circuit() to remove the manual ONE allocation, since new() now handles it.

Assumptions and Lessons

This debugging session reveals several important assumptions and their pitfalls:

Assumption: Trait defaults are safe defaults. The ConstraintSystem trait provides a default is_extensible() implementation returning false. This default exists precisely because extend() is not universally implemented. However, assuming that a constraint system implementation can safely use the default without understanding the circuit's dispatch logic proved incorrect. The FallbackPoStCircuit actively checks is_extensible() and branches accordingly — a design that assumes all constraint systems in a given proving pipeline will agree on this flag.

Assumption: Constructor semantics are uniform. The assistant initially assumed that CS::new() would produce equivalent initial states across implementations. In reality, WitnessCS::new() pre-allocates the ONE variable as a convenience for witness generation, while RecordingCS::new_empty() starts from zero. This divergence is invisible during normal operation because each CS type is used independently — it only becomes visible when the circuit dispatches to synthesize_extendable, which creates child CS instances of the same type as the parent and then merges them back.

Assumption: Extend semantics are symmetric. The assistant initially wrote extend() to skip other.num_inputs - 1 inputs, assuming the child's last input was the "temp ONE." But without a built-in ONE, the child's input 0 was the "temp ONE," and num_inputs - 1 would skip the wrong variable. The correct approach was to match WitnessCS::extend() exactly: always skip index 0 (the built-in ONE) and include everything from index 1 onward. This only works if both CS types agree that index 0 is the built-in ONE.

Input Knowledge Required

To fully understand this message, one needs knowledge of:

R1CS constraint systems: The representation of arithmetic circuits as rank-1 constraint systems, where variables are partitioned into public inputs and private auxiliary variables, and constraints are quadratic equations over these variables.
The ConstraintSystem trait: The bellpepper-core trait defining the interface for R1CS synthesis, including alloc_input, alloc, enforce, is_extensible, and extend.
CSR matrix format: Compressed Sparse Row representation of the A, B, C matrices that define R1CS constraints, and how variable indices are encoded with an AUX_FLAG to distinguish input from auxiliary columns.
The CuZK proving architecture: How PCE extraction separates topology recording from witness generation, and how RecordingCS and WitnessCS serve different roles in this pipeline.
The FallbackPoSt circuit: Filecoin's WindowPoSt circuit implementation, which uses synthesize_extendable to parallelize sector synthesis across multiple CPU cores.
Filecoin proof types: The distinction between PoRep (Proof-of-Replication), WinningPoSt, WindowPoSt, and SnapDeals, and how each has fixed circuit dimensions determined by registered proof parameters.

Output Knowledge Created

This message produced several critical insights:

The root cause of the WindowPoSt crash: A structural mismatch between RecordingCS and WitnessCS in both the is_extensible() flag and the constructor initialization.
The exact fix required: Three coordinated changes to RecordingCS — pre-allocate ONE in new(), implement extend() with proper column remapping, and update extract_precompiled_circuit() to remove the now-redundant manual ONE allocation.
A general principle for PCE correctness: Any constraint system used for PCE extraction must produce identical circuit topology to the constraint system used for fast proving. This means structural traits like is_extensible() and constructor behavior must match exactly, or the PCE will disagree with the witness on the number and arrangement of variables.
A debugging methodology for zero-knowledge proving systems: The systematic approach of implementing a feature, observing a numerical mismatch, tracing the difference to a specific flag, examining the dispatch logic, and then discovering a deeper initialization inconsistency.

The Broader Significance

This message exemplifies a class of bugs that are uniquely challenging in high-performance zero-knowledge proving systems. The proving pipeline is a complex assembly of generic traits, circuit-specific dispatch logic, GPU kernels, and caching layers. Each component makes assumptions about the others' behavior. When these assumptions diverge — as they did between RecordingCS and WitnessCS — the result is not a compiler error or a runtime panic but a subtle numerical mismatch that only manifests during GPU-resident proving with specific proof types.

The fix required understanding not just the code but the intent behind each implementation. Why does WitnessCS::new() pre-allocate ONE? Because witness generation needs a starting assignment. Why does RecordingCS::new() not pre-allocate ONE? Because recording doesn't need values, only structure. But when the circuit dispatches to synthesize_extendable, it creates child CS instances and expects them to behave identically regardless of which concrete type implements the trait. The structural role of the ONE variable — as a constant reference in linear combinations — must be consistent across all CS types in the pipeline.

The assistant's realization in this message — that the constructor mismatch is "a fundamental mismatch" — captures the moment when a superficial fix (just implement is_extensible() and extend()) gave way to a deeper understanding of the system's invariants. The ONE variable is not merely a convenience; it is a structural element of the constraint system whose position must be invariant across all implementations used in the same proving pipeline.