Reading the Resource Map: How One Message Uncovered the Memory Footprint of Filecoin's Proof Pipeline

Introduction

In the middle of an exhaustive investigation into the Filecoin proof generation pipeline, a single assistant message stands out as a pivotal moment of empirical grounding. Message 38 (global index 38) is deceptively simple: it reads three source files from the Curio storage proving system and displays their TypeDetails() methods. But this act of reading is the culmination of a deliberate search strategy, and its findings carry profound implications for the architecture being designed. This article unpacks why this message was written, what it reveals, and how its seemingly mundane content—resource declarations in Go code—became a cornerstone of the cuzk proving daemon's design.

The Message in Full

The assistant's message reads three files and shows partial content:

[assistant] [read] /home/theuser/curio/tasks/window/compute_task.go
<path>/home/theuser/curio/tasks/window/compute_task.go</path>
<type>file</type>
<content>420: 
421: func (t *WdPostTask) TypeDetails() harmonytask.TaskTypeDetails {
422: 	gpu := 1.0
423: 	ram := uint64(25 << 30)
424: 	if seal.IsDevnet {
425: 		gpu = 0
426: 		ram = 1 << 30
427: 	}
428: 
429: 	return harmonytask.TaskTypeDetails{
430: 		Name:          "WdPost",
431: 		Max:           taskhelp.Max(t.max),
432: 		MaxFailures:   5,
433: 		TimeSensitive: true,
434: 		Follows:       nil,
435: 		Cost: res...
[read] /home/theuser/curio/tasks/snap/task_prove.go
<path>/home/theuser/curio/tasks/snap/task_prove.go</path>
<type>file</type>
<content>135: 	return ids, nil
136: }
137: 
138: func (p *ProveTask) TypeDetails() harmonytask.TaskTypeDetails {
139: 	gpu := 1.0
140: 	if seal.IsDevnet {
141: 		gpu = 0
142: 	}
143: 	return harmonytask.TaskTypeDetails{
144: 		Max:  taskhelp.Max(p.max),
145: 		Name: "UpdateProve",
146: 		Cost: resources.Resources{
147: 			Cpu: 1,
148: 			Gpu: gpu,
149: 			Ram: 50 << 30, // todo correct value
150: 		},
151: 		MaxFailures:...
[read] /home/theuser/curio/tasks/snap/task_encode.go
<path>/home/theuser/curio/tasks/snap/task_encode.go</path>
<type>file</type>
<content>265: 	return preferred, nil
266: }
267: 
268: func (e *EncodeTask) TypeDetails() harmonytask.TaskTypeDetails {
269: 	ssize := abi.SectorSize(32 << 30) // todo task details needs taskID to get correct sector size
270: 	if seal.IsDevnet {
271: 		ssize = abi.SectorSize(2 << 20)
272: 	}
273: 	gpu := 1.0
274: 	if seal.IsDevnet || e.allowEncodeGPUOverprovision {
275: 		gpu = 0
276: 	}
277: 
278: 	return harmonytask.T...

At first glance, this is just three code snippets. But to understand their significance, we must trace the reasoning chain that led to this moment.

The Reasoning Chain: From Parameter Files to Resource Declarations

The assistant had been on a multi-step investigation. In the preceding messages (29–37), it was trying to determine the circuit sizes for different proof types—WindowPoSt, WinningPoSt, SnapDeals (sector updates), and PoRep. The approach was to look at the .params files, which encode the Groth16 proving parameters and whose file sizes correlate with circuit complexity.

However, the assistant hit a wall. In message 36, it ran ls -lh /var/tmp/filecoin-proof-parameters/ and found that the big .params files for 32 GiB and 64 GiB PoSt and SnapDeals were not downloaded on this machine. Only verification key files (1.4 KB each) and one 626 MiB file for a small-sector SnapDeals parameter were present. The large parameter files—which could be tens of gigabytes—were absent.

This is the critical juncture. The assistant cannot directly observe the parameter file sizes. So it pivots to a different strategy: infer resource requirements from the task definitions themselves. In message 37, the assistant explicitly states this shift:

"The big .params files for 32GiB and 64GiB PoSt and SnapDeals were not downloaded here. Let me figure out the sizes from another approach, and also check the resource requirements in the task definitions."

It then runs a grep for TypeDetails|ResourceTable|MaxMemory|Ram|Gpu|GPU across the Curio codebase, finding matches in window post, winning post, snap prove, snap encode, and snap submit tasks. Message 38 is the follow-through: reading the actual source files to see the full resource declarations.

What the Message Reveals

The three code snippets tell a story about resource allocation in the Curio proving system:

WindowPoSt (WdPostTask): Declares 25 GiB RAM and requires 1 GPU. The task is marked TimeSensitive: true, reflecting the tight 60-minute deadline for WindowPoSt submissions. On devnet, both GPU and RAM are drastically reduced (0 GPU, 1 GiB RAM), confirming that these resource declarations are tuned for mainnet-scale operations.

SnapDeals Prove (UpdateProve): Declares a whopping 50 GiB RAM and 1 GPU. The comment // todo correct value is a telling detail—even the original developers were uncertain about the exact memory requirement. This 50 GiB figure is double the WindowPoSt requirement, hinting at the significantly larger circuit for SnapDeals proofs. The assistant's investigation into parameter files had already revealed that SnapDeals has separate parameter sets for 32 GiB and 64 GiB sectors ([msg 32]), and the 50 GiB RAM declaration suggests the developers built in a safety margin.

SnapDeals Encode (EncodeTask): Uses a default sector size of 32 GiB (abi.SectorSize(32 &lt;&lt; 30)), with a telling comment: // todo task details needs taskID to get correct sector size. This reveals a known limitation—the task type details system doesn't currently have access to the specific sector size when declaring resources, so it hard-codes 32 GiB as a default. On devnet, it drops to 2 MiB sectors. GPU is required by default but can be disabled via allowEncodeGPUOverprovision.

The Deeper Significance: Why These Numbers Matter

These resource declarations are not just operational trivia. They are the constraints that any redesign must respect. The cuzk proving daemon being designed in this session ([chunk 3.0]) aims to create a pipelined, memory-efficient proving system. To do that, it needs to know:

  1. Peak memory per proof type: 25 GiB for WindowPoSt, 50 GiB for SnapDeals prove. These set the floor for SRS memory management and GPU VRAM allocation.
  2. GPU requirements: All three proof types require a GPU. This validates the design decision to build a GPU-centric proving daemon with CUDA worker pipelines.
  3. Time sensitivity: WindowPoSt is time-sensitive (must complete within the proving deadline), while SnapDeals tasks are not marked as such. This informs scheduling priority.
  4. Uncertainty margins: The // todo correct value and // todo task details needs taskID comments reveal areas where the original developers were guessing. Any new architecture should plan for measurement and validation.

Assumptions and Potential Pitfalls

The assistant makes several implicit assumptions in this message:

The resource declarations are accurate. This is a reasonable assumption for production code, but the // todo correct value comment on the 50 GiB figure suggests uncertainty. The assistant does not cross-reference these numbers against actual runtime memory measurements (e.g., from htop or CUDA profiling). In a rigorous analysis, one would want to validate these figures empirically.

The resource declarations reflect peak memory. The TypeDetails() methods are used by the Harmony task scheduler to decide whether a task can run given available resources. If the declared values are overestimates (safety margins), the scheduler may be overly conservative. If they are underestimates, tasks could OOM. The assistant treats them as authoritative.

All proof types are represented. The grep found matches for WindowPoSt, WinningPoSt, SnapDeals prove, SnapDeals encode, and SnapDeals submit. But the assistant only reads three of these. The WinningPoSt task (which declares 1 GiB RAM with a // todo arbitrary number comment, as seen in message 37) is notably absent from the read. This is a gap—WinningPoSt has a much smaller memory footprint and different scheduling characteristics.

Input Knowledge Required

To fully understand this message, one needs:

Output Knowledge Created

This message produces several concrete outputs:

  1. Confirmed RAM figures: WindowPoSt compute tasks require ~25 GiB RAM. SnapDeals prove tasks require ~50 GiB RAM. These are the first concrete memory numbers the assistant has found after failing to get parameter file sizes.
  2. GPU requirements confirmed: All three task types require GPU 1.0 (one full GPU). This validates the GPU-centric design of cuzk.
  3. Devnet vs. mainnet scaling: The devnet paths show dramatically reduced resource requirements (1 GiB RAM, no GPU), confirming that these are real-world production numbers, not development defaults.
  4. Code quality signals: The // todo comments signal areas of uncertainty in the existing codebase that the cuzk design should address with empirical measurement.
  5. Scheduling constraints: WindowPoSt is time-sensitive; SnapDeals tasks are not. This directly informs the priority scheduler design in cuzk.

The Thinking Process Visible in the Message

While the message itself is just file reads and code dumps, the thinking process is visible in the selection of which files to read. The assistant could have read any of the files matched by the grep. It chose:

  1. compute_task.go (WindowPoSt) — the most time-critical proof type
  2. task_prove.go (SnapDeals prove) — the most memory-intensive proof type
  3. task_encode.go (SnapDeals encode) — a supporting task with different characteristics This selection shows strategic thinking: the assistant is sampling the extremes of the resource spectrum (time-sensitive vs. memory-hungry vs. supporting) to build a complete mental model. It is not reading task_submit.go (64 MiB RAM, no GPU) or winning_task.go (1 GiB RAM, // todo arbitrary number) because those are less informative for the cuzk architecture—they don't stress the system. The message also shows disciplined investigation. Rather than jumping to conclusions about circuit sizes from incomplete parameter file data, the assistant pivots to a different data source (task resource declarations) and follows through by reading the actual source code rather than relying on grep snippets. This is a hallmark of thorough reverse-engineering.

Conclusion

Message 38 is a quiet but crucial moment in the cuzk architecture investigation. It transforms the assistant's understanding from "parameter files are too large to have been downloaded" to "WindowPoSt needs 25 GiB, SnapDeals needs 50 GiB, and both need a GPU." These numbers become foundational constraints for the cuzk proving daemon's SRS memory manager, GPU worker pipeline, and priority scheduler. The message also reveals the existing codebase's uncertainties (the // todo comments) and architectural patterns (devnet vs. mainnet resource scaling) that any new design must account for.

In the broader narrative of the investigation, this message represents the shift from top-down parameter analysis (trying to infer circuit sizes from file metadata) to bottom-up resource enumeration (reading the actual resource declarations in the task scheduler). It is a pragmatic adaptation to the reality that the large parameter files were not available on the development machine. And it succeeds: the assistant now has concrete, actionable numbers to feed into the cuzk architecture design.