Mapping the Parameter Landscape: How a Single Python Script Revealed the Architecture of Filecoin's Groth16 Proof Parameters

Introduction

In the course of a deep-dive investigation into the SUPRASEAL_C2 Groth16 proof generation pipeline for Filecoin's Proof-of-Replication (PoRep) system, a seemingly routine exploration of parameter files turned into a pivotal moment of architectural discovery. Message 35 in this conversation represents a turning point where the assistant, having spent the preceding messages tracing code paths through Curio's task layer, FFI bindings, and Rust proof crates, finally interrogates the actual parameter registry that governs the entire proof system. This message is remarkable not for the complexity of its code—a straightforward Python script that parses a JSON file—but for the clarity it brings to a question that had been building across more than twenty previous messages: what Groth16 proving parameters exist, for which proof types, and at which sector sizes?

Context and Motivation

The conversation leading up to message 35 had been a methodical exploration of Filecoin's proof infrastructure. The overarching investigation was focused on understanding the SUPRASEAL_C2 pipeline—a GPU-accelerated Groth16 prover used for PoRep proofs—and its relationship to the broader Curio mining software. However, a critical question had emerged organically: does SUPRASEAL_C2 handle all proof types, or is it specific to PoRep? The assistant had been tracing through Curio's task system, examining how WindowPoSt (Window Proof-of-Spacetime), WinningPoSt, and SnapDeals (sector update) proofs were generated, and whether they flowed through the same GPU-accelerated path.

By message 34, the assistant had noticed something puzzling: there appeared to be no .params files for WindowPoSt or WinningPoSt in the parameters.json registry. This was a significant observation because Groth16 proving requires large structured reference string (SRS) parameter files that encode the circuit's proving key. If WindowPoSt and WinningPoSt didn't have their own parameter files, how were their proofs generated? The assistant's working hypothesis—stated explicitly in message 34—was that these proof types might use a fundamentally different mechanism, perhaps the "proof-of-spacetime-fallback" pathway.

Message 35 is the direct follow-up to this realization. The assistant decides to "get the actual file sizes for these parameters," but the script it writes does something far more important: it systematically categorizes every parameter file in the registry by proof type and sector size, creating a complete map of the Groth16 parameter landscape.

The Script and Its Execution

The Python script executed in message 35 is deceptively simple. It opens the parameters.json file from the Lotus v1.34.4-rc1 build directory, iterates over all entries, and filters them into three categories based on naming conventions:

  1. Proof of SpaceTime (WindowPoSt/WinningPoSt) — entries containing proof-of-spacetime
  2. Empty Sector Update (SnapDeals) — entries containing empty-sector-update
  3. PoRep — entries containing stacked-proof For each entry, the script prints the truncated name, the sector_size field, and the content identifier (CID). The output reveals a striking asymmetry in the parameter landscape.

The Discovery: Asymmetry in Parameter Coverage

The script's output delivers the critical insight the assistant had been searching for. For WindowPoSt and WinningPoSt, only two parameter entries appear, both at a sector_size of 2048 bytes (2 KiB). This is an astonishingly small circuit size—essentially a toy circuit. For SnapDeals, by contrast, the parameter files span the full range of sector sizes: 2 KiB, 8 MiB, 512 MiB, 32 GiB, and 64 GiB.

This asymmetry is not an accident; it reflects a fundamental architectural difference in how Filecoin handles different proof types. WindowPoSt and WinningPoSt are fallback proofs that use a much smaller circuit because they are proving a different statement: not that a sector was correctly sealed (which requires the full PoRep circuit), but that a set of sector challenges were correctly answered at a given point in time. The "proof-of-spacetime-fallback" naming convention itself hints at the design: these proofs can fall back to a simpler, smaller circuit when the full GPU-accelerated path is unavailable.

The 2 KiB sector_size parameter for WindowPoSt/WinningPoSt is particularly telling. In the Filecoin protocol, WindowPoSt and WinningPoSt proofs do not need to prove the entire sealing process—they only need to prove that the miner still possesses the sector data at a specific time. The circuit is therefore much smaller, requiring fewer constraints and consequently smaller Groth16 parameters. The 2 KiB figure likely represents the size of a single Merkle proof path rather than an actual sector size.

Assumptions and Reasoning

The assistant's reasoning in this message reveals several important assumptions. First, the assistant assumes that the naming convention in parameters.json is a reliable indicator of proof type. The heuristic—checking for proof-of-spacetime, empty-sector-update, and stacked-proof substrings—is reasonable but carries the risk of false negatives. The assistant does not verify that every parameter file is captured by one of these three categories, nor does it check for overlapping or misclassified entries.

Second, the assistant assumes that the sector_size field in the JSON corresponds to the actual sector size the parameter file supports. This is a safe assumption given the Filecoin protocol's design, but it is worth noting that the parameter file for a 32 GiB SnapDeals proof is not itself 32 GiB in size—the sector_size field indicates the sector capacity the circuit was compiled for, not the file size.

Third, the assistant implicitly assumes that the Lotus v1.34.4-rc1 parameter set is representative and complete. Given that this is the version Curio depends on (confirmed in message 27), this is a valid assumption for the investigation's purposes.

Input Knowledge Required

To fully understand message 35, the reader needs several pieces of background knowledge:

  1. Filecoin's proof taxonomy: The distinction between PoRep (Proof-of-Replication, used during sealing), WindowPoSt (periodic proof of continued storage), WinningPoSt (proof required to win block rewards), and SnapDeals (sector update proofs for replacing sealed data). Each proof type has a different circuit with different constraints.
  2. Groth16 parameter files: Groth16 is a zk-SNARK proving system that requires a proving key (.params file) and a verification key (.vk file). These files are generated from the circuit's constraint system and can be many gigabytes in size for large circuits.
  3. The parameters.json registry: This JSON file, maintained in the Lotus build directory, maps parameter file names to their sector sizes, CIDs, and other metadata. It serves as the canonical reference for which parameter files exist and must be fetched before proofs can be generated.
  4. Curio's architecture: The assistant has been exploring how Curio (a Filecoin mining implementation) dispatches proof tasks through its FFI layer, with GPU acceleration managed by ffiselect and ffidirect packages.
  5. The SUPRASEAL_C2 context: The overarching investigation is focused on SUPRASEAL_C2, a GPU-accelerated Groth16 prover that handles the computationally intensive C2 (circuit-to-proof) stage of PoRep. Understanding which proof types use SUPRASEAL_C2 versus the standard bellperson prover is a key question.

Output Knowledge Created

Message 35 produces several concrete pieces of knowledge that advance the investigation:

  1. Confirmation that WindowPoSt and WinningPoSt use the "proof-of-spacetime-fallback" parameter set, not the full PoRep parameters. This explains why the assistant found no window or winning .params files in message 34—they are named differently.
  2. Evidence that WindowPoSt/WinningPoSt circuits are dramatically smaller than PoRep or SnapDeals circuits. The 2 KiB sector_size parameter suggests these proofs use a minimal circuit, which has implications for memory usage, proving time, and GPU utilization.
  3. A complete catalog of SnapDeals parameter files across all sector sizes (2 KiB, 8 MiB, 512 MiB, 32 GiB, 64 GiB). This is valuable for understanding the memory and storage requirements of SnapDeals proof generation.
  4. The absence of PoRep (stacked-proof) entries in the output, which is notable. The script's filter for stacked-proof found no matches, suggesting that PoRep parameters may be named differently or stored elsewhere. This is a gap that the assistant would need to investigate further.

The Thinking Process Visible in the Message

The assistant's thinking process is visible in the structure of the script and the choice of output format. The script is written incrementally: it first defines the three categories, then iterates through all parameters, classifying each one. The output is organized into clearly labeled sections, making it easy to compare the parameter sets at a glance.

The truncation of parameter names to 90 characters is a deliberate choice—the full names are extremely long (they include hash digests for content integrity), and the truncated form is sufficient for identification while keeping the output readable. The inclusion of the CID field, even though it is truncated, shows the assistant's awareness that these files are content-addressed and that the CID is the authoritative identifier for fetching them from IPFS.

The decision to print sector_size as a raw integer rather than converting to human-readable units is also telling. At this stage, the assistant is focused on exact values, not approximations. The subsequent messages (31-33) had already done the human-readable conversion; message 35 is about precision and completeness.

Mistakes and Limitations

While message 35 is successful in its primary goal, there are some limitations worth noting:

  1. The script does not handle the .vk (verification key) files separately from .params files. The output includes both, but the assistant's commentary focuses on .params files. The verification keys are typically much smaller but are equally important for the proof system.
  2. The script does not report file sizes on disk. The assistant's stated goal is to "get the actual file sizes for these parameters," but the script only reads metadata from parameters.json, not the actual file sizes. The sector_size field is not the file size—it is the sector capacity the circuit was compiled for. The actual .params files can be gigabytes in size for 32 GiB and 64 GiB sectors.
  3. The PoRep category returns no results, which is either a naming mismatch or a genuine gap. The assistant does not address this in the message, leaving it as an implicit question for future investigation.
  4. The script does not validate its assumptions about naming conventions. For example, it checks for proof-of-spacetime but not for alternative naming patterns that might exist in older versions.

Significance Within the Larger Investigation

Message 35 sits at a critical juncture in the investigation. The preceding messages had been building a picture of Curio's proof dispatch system—how tasks flow from Go through FFI into Rust and potentially into CUDA kernels. But without understanding which proof types use which parameters, the investigation could not determine whether SUPRASEAL_C2's GPU acceleration applied to all proofs or only to PoRep.

The discovery that WindowPoSt and WinningPoSt use the "proof-of-spacetime-fallback" parameter set—with its tiny 2 KiB circuit—suggests that these proofs are handled differently from PoRep and SnapDeals. The fallback pathway likely uses CPU-based proving (via bellperson) rather than GPU-accelerated SUPRASEAL_C2, because the circuit is small enough that GPU acceleration provides little benefit and the overhead of loading GPU kernels would dominate.

This insight has direct implications for the optimization proposals being developed in the broader investigation. If SUPRASEAL_C2 is only relevant for PoRep and SnapDeals, then optimization efforts should focus on those proof types. The WindowPoSt and WinningPoSt pathways, with their minimal circuits, may not benefit from GPU acceleration at all—and in fact, the overhead of GPU context switching might make CPU proving faster for these cases.

Conclusion

Message 35 is a masterclass in how a simple, well-structured query can resolve a complex architectural question. The Python script it contains is not technically sophisticated, but it is precisely targeted: it answers the question that had been building across two dozen messages of code exploration. The output reveals the fundamental asymmetry in Filecoin's proof parameter landscape—small fallback circuits for WindowPoSt/WinningPoSt, full-scale circuits for SnapDeals, and an open question about PoRep.

This message demonstrates the value of interrogating configuration data directly rather than reasoning about it from code paths alone. The assistant could have continued tracing function calls and FFI boundaries indefinitely without discovering that WindowPoSt and WinningPoSt use a fundamentally different parameter set. By going straight to the parameter registry—the source of truth for what parameters exist—the assistant short-circuits weeks of potential investigation and arrives at a clear, data-driven answer.

The message also exemplifies good investigative practice: state the hypothesis ("let me get the actual file sizes"), write a focused query, interpret the results in the context of the broader investigation, and identify the gaps that remain. It is a small but pivotal step in a much larger journey through Filecoin's proving infrastructure.