Tracing the Feature Flag: A Pivotal Dead-End in the SUPRASEAL_C2 Dependency Chain Investigation

Introduction

In the midst of a deep-dive investigation into the SUPRASEAL_C2 Groth16 proof generation pipeline for Filecoin's Proof-of-Replication (PoRep) system, a single message at index 62 captures a moment of investigative pivot. The assistant, having just uncovered the critical dispatch logic in bellperson that switches between the native Rust prover and the C++-based SupraSeal prover based on the cuda-supraseal feature flag, now attempts to trace how that flag propagates upward through the dependency chain. The message is a bash command that fails—the target file does not exist on disk. Yet this "failure" is not a dead end; it is a necessary redirection that ultimately leads to the discovery of the complete feature propagation architecture.

The Message

The message reads in full:

Now let me check the filecoin-proofs-api features to understand how cuda-supraseal propagates:

>

``bash grep -n "feature\|supraseal\|cuda\|opencl" /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/filecoin-proofs-api-19.0.0/Cargo.toml 2>&1 | head -30 ``

>

Output: `` grep: /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/filecoin-proofs-api-19.0.0/Cargo.toml: No such file or directory ``

On its surface, this is a trivial error: a file not found. But in the context of the broader investigation, this message represents a critical juncture where the assistant's mental model of the dependency graph meets the reality of what is locally cached.

Context and Motivation: Why This Message Was Written

To understand why this message exists, we must trace the investigation that led to it. In the preceding messages ([msg 50] through [msg 61]), the assistant had been systematically dissecting bellperson's prover dispatch mechanism. The key discovery was in bellperson's src/groth16/prover/mod.rs ([msg 50]), where two mutually exclusive modules are conditionally compiled:

#[cfg(not(feature = "cuda-supraseal"))]
mod native;
#[cfg(feature = "cuda-supraseal")]
mod supraseal;

#[cfg(not(feature = "cuda-supraseal"))]
use self::native as prover;
#[cfg(feature = "cuda-supraseal")]
use self::supraseal as prover;

This is the architectural hinge point of the entire proof generation system. When the cuda-supraseal feature is enabled, bellperson delegates all Groth16 proving to the C++ SupraSeal library via FFI. When it is not, the native Rust prover is used, which itself may or may not use GPU acceleration through the cuda or opencl features for multi-exponentiation and NTT operations.

The assistant had also examined the bellperson Cargo.toml ([msg 48]) and found the feature definitions:

cuda = ["ec-gpu-gen/cuda", ..., "blstrs/gpu", ...]
cuda-supraseal = ["supraseal-c2"]
opencl = ["ec-gpu-gen/opencl", ..., "blstrs/gpu", ...]

Critically, cuda-supraseal is a standalone feature that depends only on supraseal-c2—it does not include the cuda feature. This means the SupraSeal path is entirely separate from the GPU-accelerated native path. Understanding which feature is actually enabled in production requires tracing the feature flag upward through the dependency chain: from filecoin-proofs → storage-proofs-core / storage-proofs-porep / storage-proofs-post / storage-proofs-update → bellperson.

The assistant's next logical step was to examine filecoin-proofs-api, which is the top-level Rust crate exposed via C FFI to Curio's Go layer. The version in use is 19.0.0. The assistant needed to see whether filecoin-proofs-api's Cargo.toml defines a cuda-supraseal feature and, if so, how it propagates to bellperson.

The Assumption and Its Failure

The assistant assumed that version 19.0.0 of filecoin-proofs-api would be present in the local Cargo registry cache at the expected path. This was a reasonable assumption: the crate had been compiled and linked into the Curio binary, so Cargo would have downloaded and cached it. However, the path used in the command included the specific crate index identifier (6f17d22bba15001f), which is a hash of the registry index. The assistant had been successfully reading other crates from this same registry path throughout the investigation (bellperson, ec-gpu-gen, etc.), so the assumption was well-grounded.

The failure—"No such file or directory"—indicates that filecoin-proofs-api-19.0.0 was not cached at that path. Several explanations are possible: the crate may have been fetched from a different registry source, the version may have been resolved differently, or the local build may have used a vendored copy rather than a cached registry download. Whatever the cause, the immediate effect was that the assistant could not directly inspect the feature definitions for the exact version in use.

The Adaptive Response

What makes this message interesting is not the failure itself but what it reveals about the assistant's investigative methodology. Rather than treating the missing file as an insurmountable obstacle, the assistant immediately adapts. In the very next message ([msg 63]), the assistant runs a broader find command to locate any cached version of filecoin-proofs-api:

find /home/theuser/.cargo/registry/src/ -maxdepth 1 -name "filecoin-proofs-api*"

This reveals that versions 16.1.0, 17.0.0, and 18.1.0 are cached, but not 19.0.0. The assistant then makes a pragmatic decision: examine version 18.1.0 instead, reasoning that "the v19 is not cached yet. Let me check v18.1.0 which is effectively the same feature structure" ([msg 65]).

This assumption—that the feature structure is stable across versions—turns out to be correct. In message [msg 65], the assistant reads filecoin-proofs-api-18.1.0/Cargo.toml and finds:

cuda = [
    "filecoin-proofs-v1/cuda",
    "storage-proofs-core/cuda",
]
cuda-supraseal = [
    "filecoin-proofs-v1/cuda-supraseal",
    "storage-proofs-core/cuda-supraseal",
]

This confirms that the cuda-supraseal feature propagates through filecoin-proofs-v1 and storage-proofs-core. The assistant then drills deeper into filecoin-proofs-18.1.0/Cargo.toml (<msg id=66-67>) and finds the critical feature definition that shows cuda-supraseal propagating to bellperson/cuda-supraseal:

cuda-supraseal = [
    "storage-proofs-core/cuda-supraseal",
    "storage-proofs-porep/cuda",
    "storage-proofs-post/cuda",
    "storage-proofs-update/cuda",
    "bellperson/cuda-supraseal",
    "filecoin-hashers/cuda",
]

This is the smoking gun. The cuda-supraseal feature at the top level propagates bellperson/cuda-supraseal, which in bellperson triggers the supraseal module and disables the native module. Notably, it also enables cuda features for the storage-proofs sub-crates (porep, post, update) and filecoin-hashers, but not for bellperson itself. This means that when cuda-supraseal is enabled, bellperson uses the C++ SupraSeal library for the core Groth16 proving, while the surrounding proof infrastructure (Merkle tree hashing, PoRep circuit construction, PoSt circuit construction) still uses GPU acceleration through the cuda feature.

Input Knowledge Required

To understand this message, one must already be familiar with several layers of the Filecoin proof pipeline:

  1. The Curio task system: Curio is a Filecoin storage mining implementation that dispatches proof-generation tasks (Window PoSt, Winning PoSt, SnapDeals ProveCommit) through a Harmony task scheduler. Each task type declares its resource requirements (RAM, GPU) in TypeDetails() methods (<msg id=37-38>).
  2. Bellperson's prover architecture: Bellperson is a Rust library for Groth16 zk-SNARK proving, forked from the Zcash bellman library. It supports multiple proving backends: a native Rust implementation with optional GPU acceleration via ec-gpu-gen, and a C++ SupraSeal backend that handles the entire proof in dedicated C++/CUDA code.
  3. Cargo feature propagation: Rust's feature system allows conditional compilation flags to propagate through dependency trees. A top-level crate can define a feature like cuda-supraseal that enables corresponding features in its transitive dependencies.
  4. The filecoin-proofs crate hierarchy: The proof pipeline is organized as filecoin-proofs-api (C FFI layer) → filecoin-proofs (orchestration) → storage-proofs-core / storage-proofs-porep / storage-proofs-post / storage-proofs-update (circuit definitions) → bellperson (Groth16 prover) → ec-gpu-gen / supraseal-c2 (GPU compute backends).

Output Knowledge Created

This message, despite its apparent failure, creates several pieces of valuable knowledge:

  1. Negative knowledge: Version 19.0.0 of filecoin-proofs-api is not locally cached at the expected path. This is useful for future investigations—the assistant now knows to check alternative paths or use version 18.1.0 as a proxy.
  2. Methodological precedent: The assistant demonstrates a pattern of graceful degradation when a direct investigation path fails. Rather than reporting an error and stopping, the assistant broadens the search and finds an equivalent source of information.
  3. Confirmation of the feature propagation chain: Although this message itself does not produce the confirmation, it sets the stage for the subsequent messages that do. The assistant's decision to check filecoin-proofs-api was the correct next step; the only issue was the version mismatch.

The Thinking Process Revealed

The assistant's reasoning is visible in the structure of the investigation. Having discovered the bellperson dispatch logic (<msg id=50-51>), the assistant immediately recognizes the need to trace the feature flag upward. The question "how does cuda-supraseal propagate?" reveals a systems-thinking approach: the assistant is not just looking at isolated files but is building a mental model of the entire dependency graph.

The choice of filecoin-proofs-api as the next target is strategic. It is the outermost Rust crate in the FFI boundary—the crate that Curio's Go code calls into. If cuda-supraseal is enabled anywhere in the build, it must be enabled at this level (or higher, in the Go build system's Cargo configuration). By checking this crate's feature definitions, the assistant can determine whether SupraSeal is the active prover backend.

The failure message is reported without panic or confusion. The assistant simply notes the absence and moves to the next approach. This is characteristic of methodical debugging: each hypothesis is tested, and when a test fails to produce results, the hypothesis is refined rather than abandoned.

Broader Significance

In the context of the overall investigation—which aims to understand the ~200 GiB peak memory footprint of SUPRASEAL_C2 and propose optimizations—this message plays a small but crucial role. The feature propagation chain determines which prover backend is active, which in turn determines the memory profile. The native prover with GPU acceleration uses a different memory layout (CPU-side synthesis with GPU-accelerated MSM and NTT) than the SupraSeal prover (which runs entirely on GPU with its own memory management). Knowing which backend is active is essential for accurate memory accounting.

The fact that the assistant eventually confirms the cuda-supraseal feature propagation (<msg id=66-67>) means that the SupraSeal C++ backend is indeed the active prover. This validates the entire investigation's focus on SUPRASEAL_C2 and justifies the subsequent deep analysis of its memory allocation patterns.

Conclusion

Message 62 is a study in investigative resilience. A single failed bash command—a file not found—could have been a stopping point. Instead, it becomes a pivot point. The assistant adapts, finds an equivalent source, and continues the investigation. The message reveals the assistant's systematic approach to tracing dependency chains, the importance of understanding Cargo's feature propagation model, and the pragmatic willingness to work with available data even when the exact target is missing. In the narrative of the SUPRASEAL_C2 investigation, this message is the moment where the assistant confirms the investigative direction is correct, even though the immediate step fails.