Fieldwork / Rust · ZK · Systems
zk-alloc
An allocator experiment born from prover profiling. Reuse the memory, then measure where that actually matters.
The question
What if the useful optimization is a new tool, rather than another patch to the prover?
During leanVM performance work, allocator changes produced promising but hardware-dependent results. That prompted a more specific question: could an allocator take advantage of the lifecycle of repeated proof generation?
What I built
zk-alloc is a Rust bump-and-reset arena allocator for ZK proving workloads. During a proving phase it routes eligible allocations through per-thread arenas. Between phases, those arenas can reset and reuse memory pages.
The technique itself is established. The experiment was applying it to this workload and testing the boundaries. I developed the idea and the cross-prover experiments with agent-assisted implementation.
What the experiments found
The repository reports a 27% reduction in warm-proof time for leanMultisig against glibc, and 12–17% reductions for the tested Plonky3 workloads. The Jolt experiment was a null result: its compute-bound workload offered little allocator overhead to remove.
These are results for the documented benchmarks and environments, rather than a universal speedup. The null result is part of the finding: the workload’s memory behavior determines whether the idea helps.
The boundary matters
Arena allocations must not survive into a later phase that recycles their memory. Long-lived state belongs outside the arena phase. The repository documents this contract, size routing, platform behavior, and configuration.
The next useful question is where this fits safely in a production prover, and where changing the underlying allocation pattern is the better answer.
Go deeper