Most teams discover the ZK memory problem the hard way: a proof that worked on a dev laptop fails in CI, then fails again on a slightly larger circuit — not because the math is wrong, but because the prover ran out of RAM.
Peak memory is the real bottleneck
In a conventional pipeline, the prover materializes the full witness and intermediate polynomials at once. Resident memory climbs with circuit size. What looked like a small regression in constraints can push peak ZK prover RAM from a few gigabytes to tens of gigabytes overnight.
That pattern shows up everywhere:
- Rollup teams sizing prover fleets for worst-case circuits
- Bridge operators watching CI jobs fail unpredictably
- Researchers who can generate a proof locally but cannot reproduce it in production
The failure mode is almost always the same: out-of-memory (OOM). Not a logic bug. Not a soundness issue. Memory.
Why "just add RAM" stops working
Throwing hardware at the problem helps until it does not. Larger machines cost more, swap thrash makes runtime unpredictable, and container limits in Kubernetes or cloud CI cap you anyway.
Worse, peak memory is difficult to forecast. Two circuits with similar constraint counts can have very different allocation profiles depending on how the framework lays out intermediate values. Capacity planning becomes guesswork.
What teams actually need is a flat memory ceiling — one that holds regardless of how large the proof grows.
Streaming: process the witness in order
Streaming proving restructures the pipeline so the witness is consumed sequentially, not loaded wholesale. Instead of holding the entire computation graph resident, the prover advances a fixed-size working window:
- Read the next chunk of witness data
- Run the polynomial / FFT work for that chunk
- Flush completed regions before the next chunk arrives
Resident memory holds at a flat ceiling because nothing accumulates unbounded. The proof output is identical — only the schedule of work in memory changes.
This is the idea behind Snark Stream: a streaming SNARK prover designed around a bounded working set of roughly 120 MB, decoupled from circuit size.
What changes in practice
When peak memory is O(1) relative to circuit size, several things become possible:
- Proving runs on commodity CI runners instead of dedicated high-memory boxes
- The same binary deploys in a container with a hard memory limit
- Teams can plan capacity around a number instead of a distribution
Streaming does not magically make every circuit faster. It makes proving predictable — and predictability is what production infrastructure requires.
When streaming is the right fit
Streaming helps when:
- Your prover OOMs as circuits grow
- You need proofs to run under a fixed container or edge memory budget
- You want one memory profile across dev, CI, and production
It is less about raw speed and more about removing the memory cliff that blocks deployment.
The takeaway
Zero-knowledge proving is memory-bound long before it is compute-bound. Conventional architectures treat the witness as a monolith; streaming treats it as an ordered stream with a fixed resident window.
If OOM is what stops your pipeline, the fix is not always a bigger machine. Sometimes it is a different shape for how memory is used.