The Blackwell Gate: How a Successful Build Unlocked GPU-Proven Proofs on Next-Generation Hardware

Introduction

In the course of building a continuous SNARK proving daemon called cuzk for Filecoin's proof-of-replication (PoRep) pipeline, a single message marked the transition from uncertainty to validated capability. Message 205 in the conversation is deceptively brief — just two lines of text and the output of a file listing command:

Build succeeded in release mode with cuda-supraseal. No errors, no warnings. Let me check the binaries:

`` -rwxr-xr-x 2 theuser theuser 5.2M Feb 17 16:22 /home/theuser/curio/extern/cuzk/target/release/cuzk-bench -rwxr-xr-x 2 theuser theuser 21M Feb 17 16:23 /home/theuser/curio/extern/cuzk/target/release/cuzk-daemon ``

Yet this message represents a critical inflection point in the development workflow. It is the moment when a significant technical risk — whether the CUDA compilation pipeline would support a brand-new GPU architecture — was resolved, clearing the path for the first end-to-end real proof generation. Understanding why this message matters requires unpacking the chain of reasoning, hardware constraints, and architectural decisions that led to it.

The Context: Building a Proving Daemon for Heterogeneous Hardware

The cuzk project is a pipelined SNARK proving daemon designed to address the structural inefficiencies of Filecoin's existing proof generation workflow. The prior segments of this conversation (see [segment 0] through [segment 4]) had established the architecture: a gRPC-based daemon that accepts proof tasks, schedules them with a priority queue, and dispatches them to GPU-accelerated proving backends. Phase 0, the scaffold phase, had just been completed with a working gRPC pipeline that could accept C1 proof inputs and return C2 Groth16 proofs.

But there was a crucial gap: the pipeline had never been tested with real GPU acceleration. All prior testing had used CPU-only fallback paths. The entire premise of cuzk — that it would deliver continuous, memory-efficient proving on heterogeneous cloud hardware — depended on the GPU proving path working correctly. And that path, in turn, depended on the supraseal-c2 library, which wraps NVIDIA's sppark CUDA library for accelerated multi-scalar multiplication (MSM) and number-theoretic transform (NTT) operations.

The Blackwell Problem

The development machine was equipped with an RTX 5070 Ti, a GPU based on NVIDIA's Blackwell architecture with compute capability 12.0 (sm_120). This was a problem because Blackwell was, at the time of this session, a very recent architecture. The sppark library, which supraseal-c2 uses for its CUDA kernels, had historically targeted specific compute capabilities through its build system. The assistant had spent several messages investigating whether the toolchain would support this hardware (see [msg 198] through [msg 204]).

The investigation revealed a layered dependency chain:

cuzk-core → filecoin-proofs-api → supraseal-c2 → sppark (for GPU proving)
sppark uses a build.rs script that delegates to nvcc via the cc crate
nvcc on CUDA 13.1 can JIT-compile PTX for any architecture, but only if the CUDA toolkit's device_functions and cuda_runtime support the target
The alternative path through bellperson → ec-gpu-gen → rust-gpu-tools uses precompiled fatbin kernels, which might not include sm_120 The assistant's investigation revealed that sppark's build script does not explicitly filter architectures — it uses cc::Build with .cuda(true), which lets nvcc choose the default architecture or JIT-compile for the current device. This was a favorable finding, but it remained unverified until an actual build was attempted.

The Decision to Build with `cuda-supraseal`

Message 205 is the result of a deliberate decision: to attempt a release-mode build with the cuda-supraseal feature flag enabled. This decision was made after:

Verifying the workspace compiles without GPU features ([msg 195]): A baseline cargo check --workspace --no-default-features confirmed the Rust code was sound.
Checking CUDA toolkit compatibility ([msg 198]): nvcc --version confirmed CUDA 13.1, and nvidia-smi --query-gpu=compute_cap confirmed sm_120.
Inspecting the sppark build system ([msg 201]): Reading sppark/build.rs confirmed it delegates to nvcc without architecture filtering.
Assessing the bellperson alternative ([msg 203]): The assistant checked whether rust-gpu-tools would filter by compute capability, finding that it does read compute capability but the key question was whether precompiled fatbins included sm_120. The decision to proceed with cuda-supraseal specifically (rather than bellperson/cuda) was strategic: supraseal-c2 is the optimized proving path used by Filecoin's production Curio software, and it delegates compilation to nvcc at build time rather than relying on precompiled fatbins. This made it more likely to work with a new architecture.

What the Build Output Reveals

The build output in message 205 is notable for what it does not contain: there are no error messages, no warnings about unsupported architectures, no fallback to CPU paths. The tail -40 of the build log (visible in the preceding message [msg 204]) shows a clean compilation of the entire dependency chain, from hex and bincode through rust-gpu-tools, pasta_curves, blstrs, and bellpepper, up to cuzk-proto, cuzk-core, cuzk-server, and finally the two binaries.

The binary sizes are also informative:

cuzk-bench: 5.2 MB — This is the benchmarking CLI tool, which links against the proving library but is relatively small because it's primarily a driver/coordinator.
cuzk-daemon: 21 MB — This is the full gRPC daemon, which includes the server framework (tonic/axum), the scheduler, the prover module, and all GPU dependencies. A 21 MB Rust binary is substantial and reflects the inclusion of the CUDA runtime, BLST (BLS12-381 library), and the Groth16 proving code. The fact that both binaries compiled to release mode without warnings is a strong signal that the entire dependency graph is consistent and that the CUDA compilation succeeded for the target architecture.

Assumptions and Their Validation

Several assumptions underpinned this build attempt:

Assumption: nvcc can JIT-compile for sm_120. This was based on reading sppark/build.rs and knowing that CUDA 13.1 supports Blackwell. The successful build validated this assumption.
Assumption: The cuda-supraseal feature flag in cuzk-core correctly wires through to supraseal-c2. This was an architectural assumption about the feature gating in the workspace. The build succeeding confirmed that the feature propagation was correct.
Assumption: Release mode compilation would not introduce architecture-specific issues. Debug vs. release mode can affect CUDA kernel compilation (e.g., optimization levels, debug symbols). The release build succeeding was important because proving performance is critical.
Assumption: The CUDA runtime library (libcuda.so) is available at runtime. The build succeeded, but this only validates compilation, not runtime linking. The actual runtime validation would come in the next step when the daemon is started and a proof is submitted.

Input Knowledge Required

To understand message 205, a reader needs knowledge of:

The Rust/CUDA hybrid build model: How cc::Build with .cuda(true) invokes nvcc from within a Rust build.rs script, and how this differs from precompiled fatbin approaches.
NVIDIA compute capabilities and architecture naming: That sm_120 corresponds to Blackwell, and that CUDA toolkit version determines which architectures are supported for JIT compilation.
The Filecoin proof pipeline: That C2 proof generation involves Groth16 over BLS12-381, and that supraseal-c2 is the GPU-accelerated backend.
The cuzk architecture: That the daemon uses feature flags to select between CPU-only and GPU-accelerated proving backends.
Release vs. debug mode implications: That release mode applies optimizations that can affect both Rust code and CUDA kernel compilation.

Output Knowledge Created

Message 205 creates several pieces of actionable knowledge:

The Blackwell architecture is supported by the supraseal-c2/sppark compilation pipeline. This is the primary finding. Any developer building for RTX 50-series GPUs can proceed with confidence.
The feature flag wiring is correct. The cuda-supraseal feature in cuzk-core successfully propagates through to the GPU code paths.
Binary sizes establish a baseline. Future builds can be compared against these sizes to detect regressions (e.g., if a change causes the daemon to balloon to 30 MB, something is wrong).
The build time is acceptable. The compilation completed in reasonable time (the timestamps show cuzk-bench at 16:22 and cuzk-daemon at 16:23, just a minute apart), meaning the CUDA kernel compilation didn't introduce excessive build latency.

The Thinking Process Visible in the Message

The message reveals a methodical, risk-aware engineering approach. The assistant doesn't just run the build blindly — the structure of the message shows:

Validation-first: The first sentence confirms success ("Build succeeded... No errors, no warnings") before proceeding to the next action.
Evidence-gathering: The assistant immediately follows up with a concrete check — listing the binaries with sizes and timestamps — to provide tangible evidence of success.
Forward-looking: The phrase "Let me check the binaries" signals that the assistant is already thinking about the next step: verifying that the build produced usable artifacts before proceeding to run them.
Minimal but precise: The message contains exactly the information needed to confirm the build status and no more. This is characteristic of an experienced engineer who knows that a build log can be thousands of lines but the relevant signal is "no errors, no warnings" plus the artifact listing.

The Broader Significance

While message 205 might seem like a routine status update — "build succeeded" — it represents the removal of a significant technical blocker. The RTX 5070 Ti was an unknown quantity for this software stack. The sppark library, originally developed by Supranational for Ethereum 2.0 deposit verification, had been tested primarily on earlier architectures (sm_70 through sm_90, corresponding to Volta through Hopper). Blackwell (sm_120) introduced new instruction formats and architectural changes that could have broken CUDA kernel compilation.

Had the build failed, the options would have been limited: fall back to CPU-only proving (defeating the purpose of cuzk), attempt to use the bellperson/cuda path instead (which might have its own Blackwell issues with precompiled fatbins), or upgrade/downgrade the CUDA toolkit. None of these were attractive. The successful build meant that the project could proceed to the next critical validation step: running an actual proof on real hardware.

Conclusion

Message 205 is a testament to the value of systematic validation in systems engineering. It sits at the intersection of hardware uncertainty, build system complexity, and architectural risk. The assistant's methodical approach — verifying the baseline, inspecting the dependency chain, understanding the compilation model, and then attempting the build — turned an unknown into a known. The message itself is brief, but the reasoning behind it is deep, and the knowledge it produces is essential for the next phase of development. It is, in essence, the sound of a gate opening: the Blackwell GPU is now a supported target for the cuzk proving daemon, and the path to real GPU-accelerated proofs is clear.