The Quiet Pivot: Wiring a Remote GPU Proving Daemon into Curio's Task Orchestrator

In the sprawling architecture of Filecoin storage mining, few operations are as computationally demanding as Groth16 proof generation. The supraseal-c2 pipeline, which transforms sector data into zk-SNARK proofs for Proof-of-Replication (PoRep) and SnapDeals, consumes approximately 200 GiB of peak memory and requires sustained GPU compute for minutes at a time. For months, the Curio project had been optimizing this pipeline through a series of phases—reducing memory pressure, splitting GPU APIs, and adding backpressure mechanisms—all within the confines of a single-machine proving model. But in message [msg 3423], a subtle but decisive architectural shift occurred: the assistant began wiring a remote proving daemon called cuzk directly into Curio's task orchestrator, transforming how proof computation is scheduled and executed.

The message itself is deceptively brief:

Now add the cuzk client field and update constructor: [edit] /home/theuser/curio/tasks/seal/task_porep.go Edit applied successfully.

This single edit to task_porep.go represents the first concrete integration point between Curio's harmony task scheduler and the external cuzk proving daemon. To understand why this message matters, one must trace the reasoning that led to it—a chain of decisions spanning multiple segments of the conversation, each building toward a fundamental re-architecture of how proof generation is orchestrated.

The Motivation: From Local Optimization to Distributed Architecture

The context leading up to this message reveals a deliberate, multi-step implementation plan. The assistant had spent the preceding segment (Segment 32) consolidating Phase 12 of the cuzk proving pipeline—a split GPU proving API with memory backpressure that achieved 37.7 seconds per proof at pw=12 without out-of-memory errors. That phase had been a triumph of local optimization: reducing peak memory, auto-scaling channel capacity, and holding partition permits through channel sends. Yet even as Phase 12 was being documented and benchmarked, the assistant recognized a fundamental limitation: the GPU remained tied to the local machine.

The integration plan, laid out in earlier messages, was ambitious. It required:

Adding a CuzkConfig section to Curio's configuration (deps/config/types.go)
Creating a Go gRPC client library (lib/cuzk/client.go) generated from existing protobuf definitions
Creating bridge functions (lib/ffi/cuzk_funcs.go) that generate vanilla proofs locally but delegate SNARK computation to the daemon
Modifying four task types—PoRep, SnapDeals, WindowPoSt, and WinningPoSt—to use the remote daemon By message [msg 3423], steps 1 through 3 were complete. The CuzkConfig had been added to the config struct with sensible defaults (an empty address, meaning disabled). The gRPC client compiled successfully. The cuzk_funcs.go file provided PoRepSnarkCuzk and SnapProveCuzk methods that split the proof workflow: vanilla proof generation remained local (it requires access to sector data on disk), while the computationally intensive SNARK phase was shipped to the daemon via gRPC. What remained was the wiring—the delicate task of threading the cuzk.Client reference through Curio's task lifecycle without breaking the existing scheduling logic.

The Decision: How to Thread a Client Through a Task

The assistant faced a design choice with implications for the entire task scheduling system. Curio's harmony framework uses a TaskInterface pattern where each task type (PoRep, SnapDeals, proofshare) implements methods like Do(), CanAccept(), and TypeDetails(). The scheduler calls these methods to determine what work to run, where to run it, and how many resources to reserve.

The key insight, articulated in [msg 3413], was that PoRepSnark (the existing proof function) does two things: it generates a vanilla proof using GeneratePoRepVanillaProof (CPU work requiring sector data), and then runs SealCommitPhase2 (GPU SNARK computation). For the cuzk integration, only the SNARK phase could be offloaded—the vanilla proof generation must stay local because it reads sector data from the machine's storage. This meant the assistant could not simply replace PoRepSnark with a gRPC call. Instead, it created a new method PoRepSnarkCuzk that performs the vanilla proof locally and then sends the result to the daemon.

The decision to add a cuzkClient *cuzk.Client field to the PoRepTask struct, rather than using a global singleton or a context-based approach, reflects an understanding of Curio's architecture. The harmony task framework creates task instances with explicit dependencies passed through constructors. By making the client a field, the assistant ensured that each task instance has a clear, testable reference to the daemon, and that the client lifecycle is managed alongside the task lifecycle. This also allows different tasks to potentially connect to different daemon instances—a flexibility that may prove useful in multi-cluster deployments.

The Assumptions Embedded in the Edit

Every edit encodes assumptions about the system it modifies. In this case, the assistant assumed that adding a *cuzk.Client field to PoRepTask would not break the existing constructor call chain. This assumption was validated by the subsequent LSP diagnostics: the immediate error was merely that the cuzk import was unused (because the field hadn't been referenced yet in the file's methods), not that the constructor signature change had broken callers. The assistant had already verified the constructor call site in cmd/curio/tasks/tasks.go during earlier research ([msg 3380]), confirming that NewPoRepTask was called with specific parameters including cfg.Subsystems.EnablePoRepProof.

A more subtle assumption concerned the enableRemoteProofs field. The assistant had discovered earlier ([msg 3379]) that this field's name was misleading: in the PoRep task, enableRemoteProofs actually corresponds to the config value EnablePoRepProof, and when set to false, it means "proofs are done remotely" (i.e., not locally). The comment in the code read "remote proofs enabled but not local prove." This inverted logic was a potential source of confusion, and the assistant had to be careful not to conflate the existing "remote proofs" concept (which meant proofs were handled by some external system, possibly another Curio instance) with the new cuzk integration (which specifically means proofs are handled by the cuzk daemon).

Input Knowledge Required

To understand message [msg 3423], one needs familiarity with several layers of the Curio codebase. The harmony task framework's TaskInterface—with its Do(), CanAccept(), and TypeDetails() methods—is the backbone of Curio's scheduling system. The SealCalls type in lib/ffi/sdr_funcs.go provides the bridge between Go and the Rust/C++ proof generation pipeline. The cuzk protobuf definitions in extern/cuzk/cuzk-proto/proto define the gRPC service contract. And the config system in deps/config/types.go uses a nested struct pattern where subsystems are configured under CurioSubsystemsConfig.

The assistant also needed to understand the distinction between vanilla proof generation (CPU, requires sector data, stays local) and SNARK computation (GPU, can be offloaded). This distinction, which the assistant articulated in [msg 3413], is fundamental to the architecture: it means the integration is not a simple RPC call but a split workflow where the local machine retains responsibility for data-intensive operations while delegating compute-intensive operations.

Output Knowledge Created

Message [msg 3423] produced a modified task_porep.go file with a new cuzkClient field and an updated constructor. This is the first of four task types that would be modified in this chunk (the assistant would go on to modify SnapDeals in task_prove.go and proofshare in task_ps_prove.go). The edit established a pattern that would be replicated across all three files: add the client field, update the constructor, modify Do() to call the cuzk variant when enabled, adapt CanAccept() for daemon backpressure, and zero out resource requirements in TypeDetails().

The pattern itself is a form of architectural knowledge. It encodes the design principle that remote GPU proving should be invisible to the scheduler's resource accounting—when cuzk is enabled, the task reports zero GPU and RAM requirements, effectively telling the scheduler "this task is lightweight; don't reserve local GPU for it." The scheduler, in turn, relies on the daemon's queue status (queried in CanAccept()) for backpressure. This separation of concerns—local scheduling based on CPU/storage resources, remote scheduling based on daemon queue depth—is the core architectural insight of the integration.

The Thinking Process: From Research to Implementation

The assistant's thinking, visible across the preceding messages, follows a deliberate pattern. It begins with research: reading existing task implementations to understand the Do()/CanAccept() patterns (<msg id=3377-3382>). It then identifies the key architectural insight about splitting vanilla proof generation from SNARK computation ([msg 3413]). It creates the necessary infrastructure—config, client, bridge functions—before touching the task files. And finally, it approaches each task file systematically, making one focused edit at a time: first the field and constructor, then Do(), then CanAccept(), then TypeDetails().

This incremental approach is visible in the message sequence following [msg 3423]. The assistant immediately proceeds to update Do() ([msg 3424]), then CanAccept() ([msg 3425]), then TypeDetails() ([msg 3426]). Each edit is small and focused, allowing the assistant to verify correctness through LSP diagnostics before moving to the next. When errors appear—such as the "imported and not used" warning for the cuzk package—the assistant does not panic; it understands that the import will be used once the subsequent edits are applied.

Conclusion

Message [msg 3423] is, on its surface, a routine code edit: add a field, update a constructor. But within the broader narrative of the cuzk integration, it represents the moment when the architecture shifted from theory to practice. The remote proving daemon, which had existed as a standalone service with its own protobuf definitions and C++/CUDA kernels, was now being woven into the fabric of Curio's task scheduling. The edit was the first stitch in a pattern that would be replicated across three task types, transforming how Filecoin storage miners allocate their most precious resource: GPU compute.