The Critical Edit: Wiring Remote GPU Proving into Curio's Proofshare Task

Subject Message: [assistant] [edit] /home/theuser/curio/tasks/proofshare/task_prove.go Result: Edit applied successfully.

At first glance, the subject message appears to be nothing more than a mundane confirmation — a tool reporting that a file edit succeeded. Yet this single line, Edit applied successfully for the path /home/theuser/curio/tasks/proofshare/task_prove.go, represents the culmination of an intricate architectural integration effort. It is the moment when the most complex of three task types — the proofshare (PSProve) task — was finally wired to accept a remote GPU proving daemon called cuzk. To understand why this message matters, one must trace the reasoning, the design decisions, and the cascading implications that led to this edit being the correct action at this precise point in the conversation.

Context: The cuzk Integration Architecture

The broader effort was Phase 12 of a long-running optimization campaign for Filecoin's Groth16 proof generation pipeline. The cuzk daemon is a persistent GPU proving service that eliminates the overhead of loading Structured Reference Strings (SRS) for each proof, reduces peak memory from ~200 GiB to something manageable, and allows multiple Curio tasks to share a single GPU worker pool. The integration required modifying Curio's task orchestrator so that instead of running SNARK computation locally (which consumes GPU and RAM on the Curio node itself), tasks would delegate the heavy computation to the cuzk daemon via gRPC.

The integration pattern was established across three task types in order of increasing complexity:

  1. PoRep (seal) — The simplest case. The task calls SealCalls.PoRepSnarkCuzk(), a new method that generates the vanilla proof locally (which requires sector data on disk) and then sends the C1 output to cuzk for the GPU-heavy Phase2 computation.
  2. SnapDeals prove — Similar pattern. The task reads the vanilla proof from storage and sends it to cuzk via SnapProveCuzk().
  3. Proofshare (PSProve) — The most complex case, because it does not use SealCalls at all. Instead, it has package-level helper functions (computeProof, computePoRep, computeSnap) that directly invoke ffiselect.FFISelect.SealCommitPhase2 and ffiselect.FFISelect.GenerateUpdateProofWithVanilla. Integrating cuzk here required refactoring the entire call chain.

Why This Message Was Written

The subject message was written because the assistant had just finished integrating cuzk into the PoRep and SnapDeals tasks, and the proofshare task was the last remaining piece. The assistant's reasoning, visible in the preceding message ([msg 3438]), was:

"For PSProve, the computeProof function is a package-level function that directly calls ffiselect.FFISelect.SealCommitPhase2 and ffiselect.FFISelect.GenerateUpdateProofWithVanilla. To integrate cuzk here, I need to pass the client through and create cuzk-aware variants of those compute functions."

This reasoning reveals a key architectural insight: the proofshare task was structurally different from the other two. It was not built on the SealCalls abstraction layer, which already had a clean separation between vanilla proof generation and SNARK computation. Instead, it called the FFI directly. The assistant recognized that integrating cuzk here would require threading the client pointer through multiple function signatures — computeProof → computePoRep / computeSnap — a more invasive refactoring.

The edit applied in the subject message was the first step: adding the cuzkClient field to the PSProveTask struct and updating the constructor to accept it. This is the foundational change that all subsequent edits (updating Do(), CanAccept(), TypeDetails(), and the helper function signatures) would build upon.

How Decisions Were Made

The assistant made several deliberate design decisions that are visible in the surrounding conversation:

Decision 1: Consistent integration pattern across all three task types. The assistant established a uniform approach: add a cuzkClient *cuzk.Client field, modify the constructor, update Do() to call the cuzk variant when enabled, adapt CanAccept() to query the daemon's queue for backpressure, and zero out local GPU/RAM requirements in TypeDetails(). This consistency reduces cognitive overhead and makes the integration predictable.

Decision 2: Vanilla proof generation stays local; only SNARK computation is offloaded. This is a critical architectural boundary. The vanilla proof requires access to sector data on disk (sealed sectors, unsealed sectors, tickets, seeds). Moving that data to a remote daemon would add enormous I/O complexity. By keeping vanilla generation local and only sending the compact C1 output (a few kilobytes) to cuzk, the integration minimizes data transfer while still offloading the GPU-intensive work.

Decision 3: Backpressure via CanAccept() rather than resource counting. When cuzk is enabled, TypeDetails() returns zero for GPU and RAM requirements. This effectively tells Curio's scheduler that the task consumes no local resources. Instead, CanAccept() queries the cuzk daemon's queue depth to determine whether the daemon can accept more work. This shifts the scheduling decision from local resource availability to remote queue capacity — a more accurate model for a shared GPU pool.

Decision 4: Separate file for cuzk integration methods. The assistant created lib/ffi/cuzk_funcs.go to house the new PoRepSnarkCuzk and SnapProveCuzk methods on SealCalls, rather than modifying the existing sdr_funcs.go or snap_funcs.go. This keeps the cuzk-specific code isolated and makes it easy to disable or remove later.

Assumptions Made

Several assumptions underpin the edit in the subject message:

  1. The cuzk daemon is always reachable when enabled. The integration assumes that if CuzkConfig is present, the daemon is running and accepting gRPC connections. There is no fallback to local proving if the daemon is unreachable — the task would fail.
  2. The daemon's queue provides adequate backpressure. The CanAccept() method queries the daemon's queue status, but this assumes the daemon's response is timely and accurate. If the daemon is slow to respond, it could block the task scheduler.
  3. Zeroing local resource costs is safe. By returning zero GPU and RAM requirements in TypeDetails(), the assistant assumes that Curio's scheduler will not oversubscribe local resources. This is correct only if the cuzk-enabled tasks truly do not use local GPU/RAM — which they don't, since the SNARK computation happens remotely.
  4. The proofshare task's helper functions can be refactored without breaking other callers. The computeProof, computePoRep, and computeSnap functions are package-level and may be called from multiple places. Adding a *cuzk.Client parameter changes their signatures, which could break other callers if any exist.

Mistakes and Incorrect Assumptions

The cascading LSP errors that followed the subject message reveal that the assistant's initial edit was incomplete. After the edit in msg 3439, the assistant updated the Do method ([msg 3440]), which triggered:

ERROR [184:51] too many arguments in call to computeProof
    have (context.Context, harmonytask.TaskID, ProofData, *cuzk.Client)
    want (context.Context, harmonytask.TaskID, ProofData)

This error propagated through the call chain: Do() calls computeProof, which calls computePoRep and computeSnap. Each function needed its signature updated to accept the *cuzk.Client parameter. The assistant had to make three additional edits ([msg 3441], [msg 3442], [msg 3444]) to fix the cascade.

This is a classic example of a "shotgun surgery" refactoring pattern — a change that requires modifying multiple scattered functions. The assistant correctly identified the need but underestimated the number of signature changes required. The mistake was not in the design but in the execution: the edit in msg 3439 added the field and constructor but did not simultaneously update all the downstream function signatures. A more experienced approach would have been to update all signatures in a single edit, or to use the LSP's refactoring capabilities to propagate the change automatically.

Input Knowledge Required

To understand why this edit was necessary and correct, one needs:

  1. Understanding of Filecoin's proof pipeline: The distinction between vanilla proof generation (CPU, needs sector data) and SNARK computation (GPU, needs SRS) is fundamental. The integration splits these two phases.
  2. Knowledge of Curio's task architecture: The harmonytask.TaskInterface with its Do(), CanAccept(), and TypeDetails() methods. The resource accounting system that tracks GPU and RAM requirements per task.
  3. Understanding of the proofshare task's internals: Unlike PoRep and SnapDeals, PSProve uses direct FFI calls through helper functions rather than the SealCalls abstraction. This makes it structurally different and harder to integrate.
  4. Knowledge of Go's type system and LSP tooling: The assistant relied on LSP diagnostics to catch errors, which is standard Go development practice but requires understanding how the language server reports errors.

Output Knowledge Created

The edit in msg 3439, combined with the subsequent fixes, produced:

  1. A modified PSProveTask struct with a cuzkClient field that can be nil (when cuzk is disabled) or a valid client pointer (when enabled).
  2. A refactored call chain where computeProof, computePoRep, and computeSnap all accept a *cuzk.Client parameter and use it to delegate SNARK computation to the remote daemon when available.
  3. A completed integration across all three proof-related task types (PoRep, SnapDeals, PSProve), enabling Curio to offload GPU proving to a shared cuzk daemon.
  4. A documented pattern for future integrations: the combination of zeroed resource costs in TypeDetails(), daemon-based backpressure in CanAccept(), and conditional delegation in Do().

The Thinking Process Visible

The assistant's thinking process, visible in the surrounding messages, shows a methodical, iterative approach. The assistant:

  1. Researched first: Read the existing task implementations, the harmony task framework, and the FFI layer to understand the current flow.
  2. Planned the integration: Created a TODO list with research items, then systematically checked them off.
  3. Built infrastructure first: Created the lib/cuzk/client.go gRPC wrapper and the lib/ffi/cuzk_funcs.go integration methods before modifying any tasks.
  4. Integrated incrementally: Started with the simplest task (PoRep), then SnapDeals, then the most complex (proofshare). This minimized risk and allowed the pattern to be validated before tackling the hard case.
  5. Iterated on errors: When LSP errors appeared, the assistant fixed them one by one rather than trying to anticipate all changes upfront. This is a pragmatic approach but led to the cascade of signature updates. The subject message — Edit applied successfully — is the quiet pivot point in this cascade. It represents the moment when the proofshare task's struct was updated, setting the stage for the signature refactoring that followed. Without this edit, the subsequent changes to Do(), computeProof, computePoRep, and computeSnap would have had no foundation to build upon.

Conclusion

The message [edit] /home/theuser/curio/tasks/proofshare/task_prove.go — Edit applied successfully is deceptive in its brevity. It is not merely a tool confirmation; it is the record of a deliberate architectural decision to extend a remote GPU proving integration into the most complex task type in Curio's orchestrator. The edit embodies assumptions about system architecture (that SNARK computation can be cleanly separated from vanilla proof generation), design patterns (consistent integration across task types), and error handling (that LSP diagnostics will catch cascading signature mismatches). It also reveals a pragmatic, iterative development style where the assistant commits to a change, observes the consequences, and adapts. In the larger narrative of Phase 12's cuzk integration, this message marks the completion of the core implementation — the moment when all three proof-related tasks were finally wired for remote GPU proving.