The Vanishing Parameters: Discovering That PoSt Proofs Don't Use Groth16 Circuit Parameters

Message Overview

In message [msg 32] of a deep-dive investigation into Filecoin's proof generation pipeline, the assistant executes a Python script to parse the Lotus parameters.json file, filtering for Groth16 parameter files associated with WindowPoSt, WinningPoSt, and SnapDeals proofs. The script maps opaque sector-size integers to human-readable labels (32GiB, 64GiB, 512MiB, etc.), categorizes each parameter file by proof type, and prints only those matching the target categories and sector sizes. The output is startlingly sparse:

SnapDeals 32GiB: v28-empty-sector-update-merkletree-poseidon_hasher-8-8-0-3b7f44a9362e3985369454947bc94022e118211e49fd672d52bec1cbfd599d18.params
SnapDeals 64GiB: v28-empty-sector-update-merkletree-poseidon_hasher-8-8-2-102e1444a7e9a97ebf1e3d6855dcc77e66c011ea66f936d9b2c508f87f2f83a7.params

Only two parameter files exist for the target proof types and sector sizes—both for SnapDeals. WindowPoSt and WinningPoSt have no Groth16 parameters at all for 32GiB or 64GiB sectors. This negative result is one of the most consequential findings of the entire exploration session.

Why This Message Was Written: The Search for Circuit Sizes

The message sits within a broader investigation into the SUPRASEAL_C2 Groth16 proof generation pipeline, which the team had previously identified as consuming approximately 200 GiB of peak memory. The overarching goal was to design a pipelined SNARK proving daemon called cuzk (see [segment 3]), inspired by GPU inference engine architectures like vLLM and Triton. To design such a system, one must understand the resource profile of every proof type the daemon would need to serve.

The assistant had been systematically working through a checklist: explore the ffiselect GPU child-process model, trace SRS loading paths, examine bellperson's supraseal integration, and—crucially—determine the circuit sizes and parameter file footprints for each proof type. By message [msg 32], the assistant had already located the parameters.json file (in msg [msg 29]), grepped it for relevant proof types (msg [msg 30]), and run an initial Python extraction (msg [msg 31]). But that first pass had a flaw: it printed both .params and .vk (verification key) files, and it didn't cleanly separate the sector sizes.

Message [msg 32] represents a refinement step. The assistant recognized that the previous query was too noisy and that the output needed to be surgically precise to answer a specific question: "For 32GiB and 64GiB sectors, what Groth16 parameter files exist for WindowPoSt, WinningPoSt, and SnapDeals?" This precision was essential because the cuzk daemon's SRS memory manager (see the design in [chunk 3.0]) needed to know which parameter files to preload and how much memory they would consume.

How Decisions Were Made: Filtering Strategy and Heuristic Classification

The Python script in the subject message makes several deliberate design decisions:

1. Human-readable sector size mapping. The raw JSON stores sector_size as an integer (e.g., 34359738368 for 32 GiB). The script maps these to descriptive strings ('32GiB', '64GiB', '512MiB', '8MiB', '2KiB'). This is a usability decision—the output is meant to be read by a human (the assistant itself, or a future reader of the conversation) who needs to quickly grasp the scale of each parameter file.

2. Heuristic proof-type classification. The script uses simple substring matching on the parameter file name to determine the proof type: 'window' → WindowPoSt, 'winning' → WinningPoSt, 'empty-sector-update' → SnapDeals, 'stacked' → PoRep. This is a reasonable heuristic given the naming conventions observed in earlier messages, but it is an assumption that could be wrong if the naming scheme changes or if there are edge cases.

3. Output filtering. The script only prints entries where kind is one of the three target types AND sz_desc is '32GiB' or '64GiB'. This narrow focus reflects the specific question the assistant was trying to answer. It also implicitly assumes that 32GiB and 64GiB are the sector sizes of interest—which is correct for Filecoin's mainnet, but the script would miss any other sector sizes that might be relevant for testing or future proof types.

4. Excluding .vk files. The script checks name.endswith('.params'), deliberately excluding verification key files. This is because the assistant was specifically interested in the Groth16 proving parameters (which are large and memory-intensive), not the much smaller verification keys.

Assumptions Embedded in the Query

The script makes several assumptions that are worth examining:

Mistakes and Incorrect Assumptions

The most significant "mistake" revealed by this message is actually a productive misconception: the assistant had been operating under the implicit assumption that all Filecoin proof types would have Groth16 parameter files of similar magnitude. The prior optimization work (documented in the seven proposals referenced in [segment 3]) had focused heavily on the PoRep/SnapDeals C2 pipeline and its ~200 GiB memory footprint. The discovery that WindowPoSt and WinningPoSt have no parameter files at all for the target sector sizes fundamentally changes the resource model for the cuzk daemon.

A more minor issue is the classification heuristic itself. The script classifies 'empty-sector-update' as SnapDeals, which is correct for Filecoin's terminology, but the parameter filename also contains 'merkletree-poseidon_hasher' which hints at the underlying hash function. The script does not extract or report this information, which could be relevant for understanding circuit constraints.

Additionally, the script's output format is somewhat fragile—it prints the full parameter filename (which is a long hex string) without truncation. In the actual output, the line is cut off at 80 characters in the conversation rendering, making the full hash unreadable. A more robust script would print the CID or a truncated hash alongside the human-readable name.

Input Knowledge Required to Understand This Message

To fully grasp what this message accomplishes, a reader needs:

  1. Knowledge of Filecoin's proof types: PoRep (Proof of Replication for initial sector sealing), SnapDeals (sector update proofs), WindowPoSt (periodic proof of ongoing storage), and WinningPoSt (proof for block mining). Each has different circuit sizes and proving requirements.
  2. Understanding of Groth16 parameters: The .params files are structured common reference strings (SRS) used for the Groth16 zk-SNARK proving system. They are large (hundreds of MB to GB) and must be downloaded before proving can occur. The parameters.json file is a manifest that maps proof types to their required parameter files.
  3. Familiarity with the Lotus codebase: The build/proof-params/parameters.json file is part of the Lotus reference implementation of the Filecoin protocol. Its structure includes entries keyed by parameter filename, each containing sector_size, cid, and other metadata.
  4. Context from the prior exploration: The assistant had already located the correct parameters.json file (msg [msg 29]), verified its structure (msg [msg 30]), and run an initial extraction (msg [msg 31]). Message [msg 32] is the third iteration, refining the query to focus on the specific question at hand.
  5. Awareness of the cuzk design goals: The broader session was designing a pipelined SNARK proving daemon. Knowing which proof types require large parameter files directly impacts the SRS memory management strategy (see [chunk 3.0]).

Output Knowledge Created by This Message

This message produces several concrete pieces of knowledge:

1. Negative finding: No WindowPoSt or WinningPoSt Groth16 parameters for 32GiB/64GiB. This is the most important result. It means that PoSt proofs either use a different proving pathway (perhaps vanilla SNARKs without Groth16 aggregation, or smaller circuits that are generated on-the-fly) or that their parameter files are named differently than expected. This has profound implications for the cuzk architecture: the daemon may not need to manage Groth16 parameters for PoSt proofs at all, simplifying its SRS memory manager.

2. SnapDeals parameter file naming pattern. The two SnapDeals entries reveal a naming convention: v28-empty-sector-update-merkletree-poseidon_hasher-8-8-0-<hash>.params for 32GiB and v28-empty-sector-update-merkletree-poseidon_hasher-8-8-2-<hash>.params for 64GiB. The v28 prefix indicates the proof version, 8-8-0 likely encodes tree depth and partition count, and the hex suffix is a content hash. This pattern can be used to predict parameter filenames for other sector sizes.

3. Confirmation that SnapDeals uses Groth16 for both 32GiB and 64GiB. Unlike PoSt proofs, SnapDeals sector updates do require full Groth16 proving with pre-downloaded parameters. This means the cuzk daemon must be able to load and manage SnapDeals parameters, which are likely in the hundreds-of-MB range based on the sector size.

4. A reusable analysis script. The Python script itself is a reusable tool. A future investigator could adapt it to check for parameter files for any sector size or proof type, or to compare parameter sets across different Lotus versions.

The Thinking Process Visible in the Message

The subject message is a bash command invocation—the assistant's reasoning is not directly visible in the message body itself, but it can be inferred from the structure of the command and its relationship to the preceding messages.

The thinking process appears to be:

  1. Recognition of noise in prior output. The previous extraction (msg [msg 31]) printed both .params and .vk files, and used a fuzzy sector-size calculation that produced confusing output (e.g., size_gb = info.get('sector_size', 0) / (1024**3) which would produce fractional values for small sectors). The assistant realized this was too messy and needed refinement.
  2. Design of a cleaner taxonomy. The assistant designed a classification system with explicit sector-size labels and proof-type categories. This is a classic data-cleaning step: transform raw JSON into a structured, human-readable report.
  3. Focus on the decision-relevant subset. Rather than printing all entries, the assistant filtered to only the proof types and sector sizes that matter for the cuzk design. This reflects a prioritization: the daemon needs to support the most common production scenarios first.
  4. Verification through multiple approaches. The assistant didn't stop at one query. After msg [msg 32], it immediately ran a broader query (msg [msg 33]) to print all .params files across all proof types and sizes, and then explicitly noted the absence of window/winning post params in msg [msg 34]. This triangulation—checking from multiple angles—is a hallmark of rigorous investigation. The assistant's reasoning chain, reconstructed: "I need to know what Groth16 parameters exist for PoSt and SnapDeals proofs. The first query was too broad and mixed .params with .vk files. Let me write a focused script that only shows .params files, maps sector sizes to human-readable labels, categorizes by proof type, and filters to just the 32GiB/64GiB cases I care about. If WindowPoSt and WinningPoSt don't appear, that's a significant finding."

Broader Significance for the cuzk Architecture

The discovery that PoSt proofs lack Groth16 parameters has cascading implications for the cuzk proving daemon design: