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

In the long arc of integrating a custom GPU proving daemon (cuzk) into Curio—Filecoin's storage miner orchestration layer—there arrives a moment when infrastructure gives way to integration. Message [msg 3420] is that moment. It is a brief, almost telegraphic message, yet it encapsulates the entire architectural philosophy behind the cuzk integration: the careful separation of concerns between local vanilla proof generation and remote SNARK computation, the adaptation of Curio's harmony task framework to delegate GPU work, and the use of backpressure as a scheduling primitive. This article examines that single message in depth, unpacking the reasoning, decisions, assumptions, and knowledge that converge in its four bullet points.

The Message

The assistant writes:

Good - no Go-level errors. The CGO issues are from the FFI library not the code I wrote.

Now wire cuzk into the PoRep task. The approach: 1. Add cuzkClient *cuzk.Client field to PoRepTask 2. In TypeDetails(), when cuzk is enabled, zero out GPU/RAM requirements 3. In CanAccept(), when cuzk is enabled, use backpressure from daemon 4. In Do(), when cuzk is enabled, call PoRepSnarkCuzk instead of PoRepSnark [edit] /home/theuser/curio/tasks/seal/task_porep.go

On the surface, this is a simple checklist followed by an edit command. But every element carries weight from the preceding research and design work.

Context: What Led to This Message

To understand why this message exists, one must trace the session's trajectory. The assistant had spent the previous segment (Segment 33, Chunk 0) laying the groundwork for cuzk integration. This included adding a CuzkConfig section to Curio's configuration types in deps/config/types.go ([msg 3387]–[msg 3391]), creating a Go gRPC client library in lib/cuzk/client.go ([msg 3407]), generating protobuf stubs from the existing cuzk proto definitions ([msg 3397]–[msg 3406]), and—most critically—creating a new file lib/ffi/cuzk_funcs.go ([msg 3416]) that provides SealCalls methods such as PoRepSnarkCuzk.

The design of PoRepSnarkCuzk embodies a key architectural insight: in Filecoin's proof-of-replication (PoRep) pipeline, proof generation has two distinct phases. The "vanilla proof" phase (GeneratePoRepVanillaProof) requires access to the sector data on disk—it reads sealed and unsealed sector files, computes Merkle trees, and produces an intermediate representation. This phase is CPU-bound and storage-bound, and it must run on the machine that physically holds the sector. The second phase, "SNARK computation" (SealCommitPhase2), takes that intermediate representation and produces the final Groth16 proof. This phase is GPU-bound and memory-intensive, consuming ~200 GiB of RAM. The cuzk daemon was built specifically to handle this second phase remotely, pooling GPU resources across multiple miner machines.

The PoRepSnarkCuzk method therefore splits the pipeline: it calls GeneratePoRepVanillaProof locally, then sends the vanilla proof bytes to the cuzk daemon via gRPC, and finally verifies the returned proof. The local machine retains custody of sector data; the GPU-heavy work moves to a centralized proving cluster.

By message [msg 3419], the assistant had verified that lib/ffi/cuzk_funcs.go compiled without Go-level errors. The CGO (C Go bindings) errors that appeared when building lib/ffi/ were pre-existing issues from the Filecoin FFI library's FVM integration, unrelated to the new code. This clean bill of health was the trigger: the infrastructure was ready, and the actual task integration could begin.

Why This Message Was Written

The message serves three simultaneous purposes. First, it is a status confirmation: the assistant reports that the Go code compiles cleanly, signaling that the foundation is solid. Second, it is a plan announcement: the four bullet points lay out exactly what needs to happen to wire cuzk into the PoRep task. Third, it is an execution trigger: the [edit] command immediately following the plan begins the implementation.

This triple role—report, plan, act—is characteristic of the assistant's working style in this session. Rather than separating design discussion from implementation, the assistant weaves them together, announcing intent and then immediately executing. The message is the seam between preparation and action.

How Decisions Were Made

The four-point approach was not invented from scratch. It was derived from careful study of existing patterns in Curio's codebase, particularly the harmony task framework and the existing remote-proofs mechanism.

Point 1: Add cuzkClient *cuzk.Client field. This follows the standard Go pattern of dependency injection. The PoRepTask struct already held fields for database connections, storage interfaces, and configuration flags. Adding a cuzkClient field allows the task to communicate with the daemon without needing global state or service locators.

Point 2: Zero out GPU/RAM requirements in TypeDetails(). Curio's harmony scheduler uses TypeDetails() to determine a task's resource footprint. Each task type declares how many GPU cores and how much RAM it needs. When cuzk is enabled, the local machine no longer runs the GPU-intensive SNARK computation—that work is offloaded to the daemon. Therefore, the local resource requirements should be zeroed to prevent the scheduler from reserving GPU capacity that won't be used. This pattern already existed in the codebase: the PoRep task had an enableRemoteProofs flag (confusingly named—it actually means "enable local proofs") that, when set to false, caused TypeDetails() to return zero costs. The assistant recognized this pattern and adapted it for cuzk.

Point 3: Use backpressure from daemon in CanAccept(). The harmony framework calls CanAccept() to ask a task type whether it can accept more work. The existing pattern for remote proofs was to return an empty slice (meaning "accept nothing") when proofs were handled elsewhere. But the assistant went further: instead of simply rejecting all work, the plan was to query the cuzk daemon's queue depth and use that as a backpressure signal. This is a more sophisticated approach that allows the scheduler to feed work to the daemon at a rate the daemon can handle, rather than either blocking or flooding.

Point 4: Call PoRepSnarkCuzk in Do(). The Do() method is where the actual work happens. When cuzk is enabled, instead of calling the existing PoRepSnark method (which does both vanilla proof and SNARK locally), the task calls PoRepSnarkCuzk, which splits the pipeline as described above.

Assumptions Embedded in the Approach

Every design decision carries assumptions. This message is no exception.

Assumption about daemon API responsiveness. The plan assumes that CanAccept() can query the cuzk daemon's queue status quickly enough to be called frequently without introducing latency. In Curio's harmony framework, CanAccept() is called for every task scheduling decision. If each call requires a gRPC round-trip to the daemon, the overhead could become significant. The assistant implicitly assumes that either the daemon responds quickly, or that the query can be made cheap (e.g., via a cached queue depth).

Assumption about scheduler behavior with zero costs. Zeroing GPU/RAM requirements in TypeDetails() tells the scheduler that cuzk-enabled tasks consume no local resources. This is true for GPU and RAM, but the task still performs vanilla proof generation, which uses CPU and disk I/O. The assistant assumes that the scheduler's resource accounting for CPU and I/O is either negligible or handled separately.

Assumption about the inverted logic patterns. The existing codebase had two different conventions for the remote-proofs flag. In the PoRep task, enableRemoteProofs = false meant "proofs are done remotely." In the SnapDeals prove task, enableRemoteProofs = true meant the same thing. This inconsistency (discovered in [msg 3379]–[msg 3382]) could easily cause bugs if not carefully handled. The assistant's plan implicitly assumes that the cuzk integration will use a separate cuzkClient != nil check rather than relying on the existing boolean flags, thus sidestepping the confusion.

Assumption about proof verification. The plan assumes that the cuzk daemon returns a valid proof that can be verified locally. The PoRepSnarkCuzk method includes a verification step after receiving the proof from the daemon. This assumes that the daemon's proof is verifiable with the same verification function used for locally-generated proofs, which is a reasonable cryptographic assumption but one that depends on the daemon implementing the proving algorithm correctly.

Input Knowledge Required

To fully understand this message, a reader needs knowledge spanning several domains:

Curio's harmony task framework. The terms TypeDetails(), CanAccept(), and Do() are not generic—they are methods of the harmonytask.TaskInterface that every Curio task must implement. Understanding that TypeDetails() declares resource requirements, CanAccept() implements backpressure, and Do() performs the actual work is essential.

Filecoin's proof pipeline. The distinction between vanilla proof generation and SNARK computation is specific to Filecoin's proof-of-replication protocol. Vanilla proofs are CPU-bound and require sector data; SNARK proofs are GPU-bound and memory-intensive. This split is the entire motivation for the cuzk daemon.

The cuzk daemon architecture. The reader must know that cuzk is a remote GPU proving daemon built in earlier phases of this session (Phases 10–12), that it communicates via gRPC, and that it accepts vanilla proof bytes and returns final proofs.

Go and protobuf conventions. The message assumes familiarity with Go gRPC client patterns, protobuf code generation, and the standard Go project layout.

Output Knowledge Created

This message, combined with the edit that follows it, creates several outputs:

A modified task_porep.go that includes a cuzkClient field, updated TypeDetails(), CanAccept(), and Do() methods. This file becomes the template for all other task integrations (SnapDeals prove, proofshare, and eventually WindowPoSt and WinningPoSt).
An architectural pattern for integrating remote proving into Curio: add client field, zero local costs, query daemon for backpressure, call split method in Do(). This pattern is applied consistently across all proof-related tasks in the subsequent messages ([msg 3422]–[msg 3445]).
A validation of the split-pipeline design. By successfully wiring the PoRep task to use PoRepSnarkCuzk, the assistant confirms that the earlier design decision—splitting vanilla proof generation from SNARK computation—is implementable within Curio's existing task framework.

The Thinking Process Visible in the Message

Though brief, the message reveals the assistant's reasoning process. The opening line—"Good - no Go-level errors. The CGO issues are from the FFI library not the code I wrote."—shows a diagnostic thought process. The assistant ran a build, saw errors, filtered them to determine which were relevant, and concluded that the new code was clean. This is the thinking of an experienced developer who knows how to distinguish signal from noise in build output.

The four bullet points are ordered by dependency. Point 1 (add the field) must come first because points 2–4 all depend on having a cuzkClient to check. Point 2 (TypeDetails) and point 3 (CanAccept) are about scheduling and resource accounting, which happen before point 4 (Do), where the actual work occurs. This ordering reflects an understanding of the task lifecycle: first the scheduler decides whether to accept (CanAccept), then it accounts for resources (TypeDetails), then it executes (Do).

The immediate [edit] command after the plan shows that the assistant treats planning and execution as a single continuous process. There is no separate "design review" step—the design is validated by implementation.

Conclusion

Message [msg 3420] is a pivot point in a much larger integration effort. It marks the transition from building infrastructure (config, client library, split methods) to integrating that infrastructure into Curio's core task orchestration. The four bullet points distill weeks of architectural reasoning—the split-pipeline design, the backpressure mechanism, the resource accounting strategy—into a concrete implementation plan. The message is simultaneously a status report, a design document, and an execution command. In its brevity and precision, it exemplifies the kind of thinking that turns architectural vision into working code.