The Quiet Edit: Wiring Remote GPU Proving into Curio's SnapDeals Task

A Single Line of Confirmation Carrying Architectural Weight

On the surface, message [msg 3431] is almost absurdly minimal:

[assistant] [edit] /home/theuser/curio/tasks/snap/task_prove.go Edit applied successfully.

Two lines. A file path. A confirmation. Nothing more. Yet this message sits at the precise inflection point where months of GPU optimization work — the Sequential Partition Synthesis, the Persistent Prover Daemon, the Phase 12 split API with its memory backpressure and channel capacity auto-scaling — finally meets the production task orchestrator that will drive it in the real Filecoin network. This edit is not a change to a single file; it is the culmination of an entire architectural vision, the moment when a remote proving daemon becomes a first-class citizen in Curio's task scheduling ecosystem.

To understand why this message matters, one must understand the journey that led to it. The broader session (Segment 33) had been working on two parallel tracks: finalizing the Phase 12 split GPU proving API with its low-memory benchmark sweep, and then planning the integration of the cuzk proving daemon into Curio's task orchestrator. The cuzk daemon was the result of a long optimization campaign — a persistent process that loads SRS (Structured Reference String) data once, keeps GPU state alive across proof requests, and streams partitions sequentially to keep peak memory at ~69 GiB instead of the original ~200 GiB. But a daemon is useless without clients. The integration work was about making Curio's existing tasks — PoRep (seal), SnapDeals prove, proofshare, and WindowPoSt — delegate their SNARK computation to this daemon rather than running it locally.

The Pattern Established

Message [msg 3431] is the second edit to tasks/snap/task_prove.go in a sequence that mirrors the PoRep integration completed just moments earlier. The first edit, in [msg 3430], had added the import "github.com/filecoin-project/curio/lib/cuzk" to the file's import block. That edit triggered an LSP error: the import was unused. Message [msg 3431] is the response — the edit that actually uses the import by adding a cuzkClient *cuzk.Client field to the ProveTask struct and modifying its constructor to accept it.

The pattern had been established in the PoRep task ([msg 3420] through [msg 3426]), where the assistant articulated a four-point plan:

1. Add cuzkClient *cuzk.Client field to the task struct
2. In TypeDetails(), when cuzk is enabled, zero out GPU/RAM requirements
3. In CanAccept(), when cuzk is enabled, use backpressure from the daemon's queue
4. In Do(), when cuzk is enabled, call the remote proving method instead of the local one This pattern represents a fundamental shift in how Curio thinks about resource accounting. Normally, each task type declares its GPU and RAM requirements in TypeDetails(), and the harmony scheduler uses those to decide whether a task can run on the local machine. When cuzk is enabled, those requirements are zeroed — the task becomes "weightless" from the scheduler's perspective. The actual resource management moves to the daemon's queue, queried via CanAccept(). This is a clever architectural inversion: the scheduler no longer needs to know about GPU availability; it just needs to know whether the daemon has capacity.

The SnapDeals Task: A Second Integration Point

The SnapDeals prove task (tasks/snap/task_prove.go) is the second of three task types being wired in this chunk. PoRep was first, SnapDeals is second, and proofshare will follow. Each follows the same pattern but has its own nuances. The SnapDeals task, for instance, has an inverted enableRemoteProofs logic compared to PoRep — it uses cfg.Subsystems.EnableRemoteProofs (when true, meaning "don't do locally") whereas PoRep uses cfg.Subsystems.EnablePoRepProof (when false, meaning "don't do locally"). The assistant had discovered this discrepancy during research ([msg 3382]) and noted it. The cuzk integration overrides both of these legacy mechanisms with a single CuzkConfig.Enabled flag.

The edit in [msg 3431] is specifically the structural change: adding the field and updating the constructor. The subsequent edits ([msg 3432], [msg 3433], etc.) will update Do(), CanAccept(), and TypeDetails() respectively. The assistant is working through the integration methodically, one concern at a time, treating each task type as a transformation pipeline with four distinct edits.

Reasoning and Decision-Making

The assistant's reasoning, visible in the surrounding messages, reveals several key decisions:

Why not modify SealCalls.PoRepSnark directly? The assistant considered this approach and rejected it ([msg 3413]). The vanilla proof generation must remain local because it needs access to sector data on the machine's storage. Only the SNARK computation (GPU-bound) can be offloaded. Creating separate PoRepSnarkCuzk and SnapProveCuzk methods on SealCalls (in lib/ffi/cuzk_funcs.go, [msg 3416]) keeps the concerns cleanly separated.

Why zero out resource requirements instead of adjusting them? This is the most architecturally significant decision. By setting GPU and RAM to zero in TypeDetails(), the assistant ensures that Curio's scheduler treats cuzk-enabled tasks as having no local resource footprint. This means multiple such tasks can be "accepted" simultaneously — they're not competing for local GPU. The actual admission control happens at the daemon level via CanAccept(), which queries the daemon's queue depth. This two-level scheduling (Curio's local scheduler + daemon's queue) is a deliberate design for heterogeneous deployments where GPU resources are remote.

Why hold the partition permit through channel send? This was a lesson learned from Phase 12's memory pressure debugging ([msg 3430] context). The permit-based backpressure system ensures that the daemon doesn't accept more work than it has memory for. By propagating this permit through the gRPC call, the integration maintains the memory guarantees that were so carefully engineered in the Phase 12 work.

Assumptions and Their Risks

The integration makes several assumptions worth examining:

The daemon is always reachable. If the cuzk daemon goes down, tasks that have been configured for remote proving will fail. The CanAccept() method returns empty (no tasks accepted) when the daemon is unreachable, which provides a graceful degradation — tasks queue up in Curio's database rather than failing immediately — but the system cannot fall back to local proving. This is an explicit design choice: the configuration is all-or-nothing for a given task type.

Network latency is acceptable. The gRPC calls to the daemon add round-trip latency. For the SNARK computation itself (tens of seconds), this is negligible. But the CanAccept() call happens frequently and must be fast. The assistant assumes that a lightweight queue-depth query is cheap enough to not impact scheduler performance.

The daemon's queue provides sufficient backpressure. The integration replaces Curio's local resource accounting with the daemon's queue. If the daemon's queue implementation has bugs or doesn't accurately reflect memory pressure, the system could accept more work than the daemon can handle. The Phase 12 memory backpressure work was specifically designed to prevent this, but the integration adds a network boundary that could mask issues.

Input and Output Knowledge

To understand this message, one needs input knowledge spanning several domains: Curio's harmony task framework (the TaskInterface with its Do(), CanAccept(), TypeDetails() methods), the existing SnapDeals prove task implementation, the cuzk gRPC protobuf definitions, the Go gRPC client library generated from those protos, and the architectural pattern established in the PoRep integration just minutes earlier. One also needs to understand the broader optimization campaign — the Phase 12 split API, the memory backpressure system, and the decision to split vanilla proof generation from SNARK computation.

The output knowledge created by this message is a modified task file that, once the subsequent edits are applied, will delegate SnapDeals SNARK computation to the remote daemon. This is not just a code change; it's a new capability. Curio gains the ability to run SnapDeals proof generation without local GPUs, relying instead on a dedicated proving cluster. For Filecoin storage providers, this means they can separate storage capacity (cheap, high-density) from proving capacity (GPU-intensive, memory-hungry), potentially reducing costs by running GPUs only where they're fully utilized.

The Thinking Process

The assistant's thinking, visible in the surrounding messages, reveals a methodical, pattern-driven approach. Having established the four-step integration pattern for PoRep, the assistant applies it to SnapDeals with minimal adaptation. The research phase ([msg 3381] through [msg 3382]) uncovered the inverted enableRemoteProofs logic, which the assistant noted but did not let derail the integration — the cuzk flag overrides both legacy mechanisms uniformly.

The assistant also demonstrates awareness of build constraints. When the CGO/FVM errors appear ([msg 3417]), the assistant correctly identifies them as pre-existing environment issues unrelated to the integration work, and uses go vet with build tags to verify Go-level correctness. This pragmatic approach — verify what you can, acknowledge what you can't — is characteristic of real-world systems integration where the development environment is never perfectly aligned with the production build.

Most importantly, the assistant shows a deep understanding of the architectural implications of each edit. Adding a cuzkClient field is not just wiring; it's changing the resource model of the task. Zeroing TypeDetails() is not just a configuration tweak; it's inverting the scheduling paradigm. Each edit carries architectural weight, and the assistant treats it accordingly — methodically, deliberately, one task type at a time.