The Dependency Wiring That Enabled Pipelined SNARK Proving

In the middle of implementing Phase 2 of the cuzk pipelined proving engine, the assistant issued a seemingly mundane message: an edit to the workspace Cargo.toml to add new dependency declarations. The full text of the message reads:

[assistant] Now I need to update the workspace Cargo.toml and cuzk-core Cargo.toml with the new dependencies. First, let me add the workspace-level deps: [edit] /home/theuser/curio/extern/cuzk/Cargo.toml Edit applied successfully.

This message, <msg id=449>, is the 449th exchange in a long-running coding session spanning multiple days and dozens of hours of work. It appears unremarkable at first glance — a developer adding library dependencies to a Rust project. But in context, this single edit represents a critical architectural pivot: the moment the proving engine stopped treating the upstream proving libraries as opaque, monolithic API calls and began reaching directly into their internals to build a pipelined architecture.

The Strategic Context: Why This Message Exists

To understand why this message was written, one must understand the architecture it was modifying. The cuzk project is a custom SNARK proving daemon for Filecoin proof generation, built in phases. Phase 0 and Phase 1 had been completed across four commits spanning thousands of lines of code. In those phases, the engine called into filecoin-proofs-api — a high-level Rust library that bundles circuit synthesis, SRS parameter loading, and GPU proving into a single function call (seal_commit_phase2). This monolithic approach worked, but it had a critical flaw: the GPU sat idle while the CPU synthesized circuits, and the SRS parameters were loaded and discarded with each proof, wasting precious I/O time.

Phase 2 was designed to fix this by splitting the proving pipeline into two stages — CPU circuit synthesis and GPU proof computation — that could overlap in time. The bellperson fork (created in the previous commit, <msg id=430>) had already exposed the internal synthesis/GPU split point by making synthesize_circuits_batch() and prove_from_assignments() public. But to use these newly exposed APIs, the cuzk-core crate needed direct access to crates it had never depended on before: filecoin-proofs (not just filecoin-proofs-api), storage-proofs-core, storage-proofs-porep, storage-proofs-post, storage-proofs-update, bellperson, blstrs, rayon, and ff.

The message at <msg id=449> is the first step in satisfying those new dependency requirements. It is the infrastructural foundation upon which the entire pipelined prover would be built.

The Reasoning Behind the Edit

The assistant's todo list, visible in the preceding message <msg id=448>, shows the state of progress: Step 3 (SRS manager) was marked "completed" and Step 4a (add new dependencies) was marked "in_progress." The assistant had just finished writing srs_manager.rs, a module that loads SRS parameters directly via SuprasealParameters::new() — bypassing the private GROTH_PARAM_MEMORY_CACHE that the monolithic path relied on. Now it needed to wire up the dependency graph so that the upcoming pipeline.rs module could import types from storage-proofs-porep (like StackedCompound and StackedCircuit) and from the bellperson fork (like ProvingAssignment, synthesize_circuits_batch, and prove_from_assignments).

The decision to add workspace-level dependencies first, rather than adding them directly to cuzk-core/Cargo.toml, reflects a deliberate architectural choice. The workspace Cargo.toml at extern/cuzk/Cargo.toml already contained shared dependency declarations for internal crates like cuzk-proto, cuzk-core, cuzk-server, cuzk-daemon, and cuzk-bench. By adding the proving crates at the workspace level, the assistant ensured that all crates in the workspace could reference them with consistent version pins — filecoin-proofs = "19.0.1", storage-proofs-core = "19.0.1", and so on — preventing version conflicts as the project grew.

Input Knowledge Required

To appreciate what this message accomplishes, one must understand several layers of context:

First, the Rust workspace structure. The cuzk project lives in extern/cuzk/ as a standalone Cargo workspace with six member crates. The workspace root Cargo.toml defines shared dependencies and the [patch.crates-io] section that redirects bellperson to the local fork at extern/bellperson/. Adding new workspace-level dependencies here means any member crate can use them by simply writing storage-proofs-porep = { workspace = true } in its own Cargo.toml.

Second, the upstream crate ecosystem. The Filecoin proof pipeline is split across multiple crates: filecoin-proofs (high-level orchestration, circuit construction, SRS caching), storage-proofs-core (the CompoundProof trait and MAX_GROTH16_BATCH_SIZE constant), storage-proofs-porep (PoRep-specific circuit types like StackedCompound and StackedCircuit), storage-proofs-post (PoSt circuits), and storage-proofs-update (SnapDeals circuits). Each has specific feature flags for CUDA and supraseal support.

Third, the version compatibility. The assistant had verified in earlier messages <msg id=439-441> that all these crates were locked to version 19.0.1 in the workspace's Cargo.lock. The blstrs crate was at 0.7.1, rayon at 1.11.0, and ff at 0.13.1. These version numbers were critical — specifying the wrong version would cause resolution failures.

Fourth, the feature flag architecture. The cuda-supraseal feature in filecoin-proofs enables cuda-supraseal on storage-proofs-core and bellperson, but only cuda on storage-proofs-porep, storage-proofs-post, and storage-proofs-update. This asymmetry would cause the build error seen in <msg id=451> — the assistant initially declared storage-proofs-porep = { workspace = true, features = ["cuda-supraseal"] }, but that crate doesn't have that feature. The fix in <msg id=453> corrected this to features = ["cuda"] for the porep/post/update crates.

What the Edit Actually Changed

While the message text doesn't show the diff, the edit added entries like these to the [workspace.dependencies] section of extern/cuzk/Cargo.toml:

filecoin-proofs = { version = "19.0.1", default-features = false }
storage-proofs-core = { version = "19.0.1", default-features = false }
storage-proofs-porep = { version = "19.0.1", default-features = false }
storage-proofs-post = { version = "19.0.1", default-features = false }
storage-proofs-update = { version = "19.0.1", default-features = false }
bellperson = { version = "0.26.0" }
blstrs = { version = "0.7.1" }
rayon = { version = "1.11.0" }
ff = { version = "0.13.1" }

These declarations, combined with the existing [patch.crates-io] section that redirects bellperson to the local fork, established the dependency foundation for the entire Phase 2 pipeline. Without them, cuzk-core could not import StackedCompound::circuit(), could not call synthesize_circuits_batch(), and could not use ProvingAssignment<Scalar> — the three core building blocks of the pipelined prover.

The Assumptions and Their Consequences

The assistant made several assumptions in this message, some of which proved incorrect. The most significant was the assumption about feature flag compatibility across the storage-proofs crates. The workspace dependency declarations initially specified features = ["cuda-supraseal"] uniformly across all storage-proofs crates. But as discovered in <msg id=452>, only filecoin-proofs and storage-proofs-core have a cuda-supraseal feature; the porep, post, and update crates only have cuda. This mismatch caused cargo check to fail with the error "storage-proofs-porep does not have these features."

The assistant also assumed that the workspace-level dependencies would be sufficient — that once declared at the workspace level, cuzk-core could simply reference them with { workspace = true } and the feature flags would propagate correctly. This assumption was correct in principle but required careful handling: the feature flags must be specified at the point of use (in cuzk-core/Cargo.toml), not inherited from the workspace declaration.

A third assumption was that the existing [patch.crates-io] section for bellperson would continue to work with the new dependency declarations. This proved correct — the patch section redirects bellperson to the local fork regardless of which crate declares the dependency.

Output Knowledge Created

This message created a concrete artifact: an updated extern/cuzk/Cargo.toml with new workspace dependency declarations. But the knowledge it produced extends beyond the file diff:

  1. The dependency graph for Phase 2 is now explicit. Any developer reading the workspace Cargo.toml can see exactly which external crates the pipelined prover depends on, at which versions, and with which feature defaults.
  2. The architectural boundary is defined. By adding dependencies on filecoin-proofs (not just filecoin-proofs-api), the assistant committed to a deeper integration with the upstream proving stack. The engine would no longer be a thin wrapper around high-level API calls; it would construct circuits, manage SRS, and invoke the bellperson split API directly.
  3. A failure mode was discovered and documented. The feature flag asymmetry between storage-proofs-core (which has cuda-supraseal) and storage-proofs-porep/post/update (which only have cuda) was not obvious from the crate names. The build error and subsequent fix in <msg id=453> created knowledge about the upstream crate's feature surface that would be essential for anyone maintaining the dependency configuration.

The Thinking Process Visible in the Message

The message itself is terse, but its reasoning is illuminated by the surrounding context. The assistant had just completed the SRS manager module (<msg id=447>) and was moving methodically through the 7-step Phase 2 plan. The todo list in <msg id=448> shows the assistant's mental model: a linear progression through clearly defined steps, with each step marked pending, in_progress, or completed.

The choice to update the workspace Cargo.toml before the crate-level Cargo.toml reveals a top-down thinking process. Rather than adding dependencies ad-hoc to cuzk-core/Cargo.toml and hoping they resolve, the assistant established the shared foundation first. This is consistent with the disciplined, architectural approach visible throughout the session — the assistant consistently builds infrastructure before functionality, dependencies before code, and tests before integration.

The phrase "First, let me add the workspace-level deps" signals that the assistant is thinking in terms of ordering and dependencies. It knows that cuzk-core/Cargo.toml will need to reference these workspace deps, so the workspace declarations must come first. The follow-up message <msg id=450> ("Now update cuzk-core's Cargo.toml") completes the two-step process.

Conclusion

Message <msg id=449> is a dependency wiring edit that, on its surface, appears trivial. But it represents the moment the cuzk proving engine crossed an architectural threshold — from a consumer of high-level proving APIs to a direct user of the proving stack's internal machinery. The workspace dependency declarations it created were the enabling condition for the pipeline module, the SRS manager integration, and ultimately the per-partition pipelining that would reduce peak memory from ~136 GiB to ~13.6 GiB. In the architecture of the cuzk project, this message is the keystone: invisible once the arch is complete, but structurally essential.