The Pivot Point: Discovering the Bellperson Prover Triad

Introduction

In the course of a deep-dive investigation into Filecoin's SUPRASEAL_C2 Groth16 proof generation pipeline, a single, seemingly modest message marks a critical turning point. Message <msg id=42> reads:

Now I can see the critical files. Let me read the prover mod, native, and supraseal paths: [read] /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bellperson-0.26.0/src/groth16/prover/mod.rs [read] /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bellperson-0.26.0/src/groth16/prover/supraseal.rs [read] /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bellperson-0.26.0/src/groth16/prover/native.rs

This message is a transitional artifact — a moment of recognition that the investigation has reached its quarry. After tracing through layers of Go task orchestration, Rust FFI bindings, and Cargo dependency trees, the assistant has finally located the three source files that constitute the heart of the Groth16 prover: the module dispatcher (mod.rs), the GPU-accelerated supraseal path (supraseal.rs), and the CPU-based native path (native.rs). This article examines why this message was written, what it reveals about the investigation's methodology, and the knowledge it both presupposes and creates.

Context and Motivation: The Long Trail to the Prover

To understand the significance of <msg id=42>, one must appreciate the investigative journey that preceded it. The root session was tasked with mapping the full call chain of the SUPRASEAL_C2 proof generation pipeline — from Curio's Go-level task scheduling, through Rust FFI into C++/CUDA kernels — and accounting for its notorious ~200 GiB peak memory footprint. The investigation had already produced extensive background documentation, identified nine structural bottlenecks, and proposed three optimization strategies.

The immediate sub-task that led to <msg id=42> was to "Explore SnapDeals/PoSt circuit sizes." But the assistant's approach was characteristically systematic: rather than jumping directly to circuit parameters, it traced the entire proof generation pathway from the top down. Messages <msg id=19> through <msg id=41> show a meticulous traversal:

The Message as a Methodological Artifact

Message <msg id=42> is not a typical assistant response — it contains no analysis, no conclusions, no code snippets. It is purely a statement of intent followed by three file-read commands. Yet this brevity is itself revealing. The message serves several functions:

1. A Verbal Landmark

The phrase "Now I can see the critical files" signals that the assistant recognizes it has reached a structural inflection point. After dozens of grep searches, file reads, and parameter queries, the investigation has narrowed from the broad codebase to the specific implementation files that control proof generation. This is the investigative equivalent of "we have arrived."

2. A Methodological Commitment

By naming the three files explicitly — mod.rs, supraseal.rs, native.rs — the assistant reveals its hypothesis about the code architecture. It assumes that:

3. A Demonstration of Systematic Investigation

The assistant does not jump to conclusions. It has found the files and now reads them in full before offering any analysis. This reflects a methodological principle: understand the code before characterizing it. The investigation has been building a layered understanding — from task scheduling → FFI dispatch → Rust crate structure → now the prover implementation itself.

Input Knowledge Required

To understand <msg id=42> and its significance, a reader needs substantial context:

Rust Crate Structure

The paths reveal that bellperson follows standard Rust conventions: a groth16/ module containing submodules for the prover. The presence of supraseal.rs alongside native.rs implies a compile-time or runtime selection mechanism, likely gated by Cargo feature flags (e.g., #[cfg(feature = "cuda")] or similar).

The Bellperson Library

Bellperson is Filecoin's fork of the Bellman zk-SNARK library, customized for the Filecoin proof-of-replication and proof-of-spacetime circuits. It implements Groth16 proving with GPU acceleration via CUDA and OpenCL backends. Understanding that bellperson is the core proving library — and that it has both CPU and GPU paths — is essential.

The Investigation's Prior Findings

The reader must know that the assistant has already:

The Supraseal Naming Convention

The term "supraseal" appears in both the Cargo dependency (supraseal-c2) and the bellperson source file (supraseal.rs). This is not coincidental — the assistant correctly infers that supraseal.rs wraps the C++/CUDA supraseal-c2 library, providing the GPU-accelerated proving path.

Output Knowledge Created

Message <msg id=42> itself creates no direct output — it is a transitional action. But it sets the stage for the knowledge that will be produced in subsequent messages:

The Dispatch Mechanism

Reading mod.rs will reveal how bellperson chooses between the native and supraseal provers. This is critical for understanding when GPU acceleration is used versus CPU-only proving, and whether the choice is made at compile time (via feature flags) or runtime (via environment variables or configuration).

The Supraseal Interface

Reading supraseal.rs will expose the API boundary between Rust and the C++/CUDA supraseal-c2 library. This includes function signatures, memory ownership patterns, and data transfer mechanisms — all essential for understanding the ~200 GiB memory footprint.

The Native Fallback

Reading native.rs will reveal the CPU-only proving implementation. This is important for two reasons: (1) it serves as a baseline for understanding the computational complexity of Groth16 proving, and (2) it may reveal opportunities for CPU-side optimizations that complement the GPU path.

Assumptions and Potential Pitfalls

The assistant makes several assumptions in <msg id=42> that warrant examination:

Assumption 1: The Tripartite Structure is Complete

The assistant assumes that mod.rs + supraseal.rs + native.rs constitute the complete prover. But there could be additional files — for example, an opencl.rs path, or a prover/cpu.rs that is distinct from native.rs. The directory listing in <msg id=41> showed only these three files under prover/, so the assumption is well-founded, but it should be verified.

Assumption 2: "Native" Means CPU-Only

The term "native" could be misleading. It might refer to a Rust-native implementation that still uses GPU acceleration through a different mechanism than supraseal. The assistant implicitly assumes that native.rs is the CPU fallback, but this needs confirmation.

Assumption 3: The Files Contain the Full Logic

The assistant assumes that reading these three files will reveal the complete prover architecture. However, critical logic may reside in helper modules (e.g., multiexp.rs, fft.rs) or in the supraseal-c2 C++ library itself, which is not part of the bellperson crate.

The Thinking Process Visible in the Message

While <msg id=42> is brief, the reasoning behind it is visible when read in context:

  1. Recognition of significance: The assistant has been searching for "where the proof is actually computed." After finding parameter files, task definitions, and FFI bindings, it now traces into the proving library itself.
  2. Prioritization of files: The assistant chooses to read all three files simultaneously (issuing three [read] commands in one message). This indicates that it expects to need all three to understand the architecture — it's not reading incrementally but strategically.
  3. Naming as a guide: The assistant uses file naming conventions as a map. The names mod, supraseal, and native are descriptive enough to suggest their roles before any code is read.
  4. The "critical" judgment: The assistant declares these files "critical" based on their position in the call chain. It has traced from Curio tasks → FFI → bellperson crate → groth16 module → prover submodule. These files are the leaves of that tree — the actual implementation.

Conclusion

Message <msg id=42> is a quiet pivot point in a complex investigation. It represents the moment when the search for where proof generation happens gives way to the analysis of how it happens. The assistant's decision to read the three prover files simultaneously — rather than incrementally — reflects a strategic understanding that the architecture can only be understood by seeing all three paths together.

This message also exemplifies a core investigative virtue: the willingness to follow the code wherever it leads, from Go task definitions through Rust FFI into the Cargo registry's cached source files. The assistant does not speculate about what supraseal.rs contains; it reads it. It does not assume the dispatch mechanism; it reads mod.rs. This commitment to empirical investigation — reading the actual source rather than inferring from documentation or naming — is what makes the subsequent analysis trustworthy.

The three files listed in <msg id=42> will, in the messages that follow, reveal the precise mechanism by which Filecoin's Groth16 proofs are generated, the conditions under which GPU acceleration is engaged, and the memory allocation patterns that produce the ~200 GiB peak. But in this moment, they are still terra incognita — three files waiting to be read, their secrets waiting to be extracted.