The only production STARK prover with O(√N) memory.
Every other production STARK system needs O(N) memory — linear in the size of the computation, where N is the number of trace steps. A 100M-step proof needs hundreds of GB of RAM, or aggressive segmentation and recursive aggregation. TinyZKP needs only O(√N) — that same proof fits comfortably on a 16 GB laptop. Same cryptographic guarantees: ≥128-bit soundness, transparent, post-quantum.
The structural advantage, in numbers
| Computation size (N) | Conventional STARK — O(N) | TinyZKP — O(√N) |
|---|---|---|
| 1M steps | 10–20 GB RAM | ~30 MB |
| 10M steps | 100+ GB RAM | ~100 MB |
| 100M steps | Fleet sharding required | ~300 MB |
| 1B steps | Not feasible without segmentation + recursion | ~1 GB |
The trade-off is honest: extra time for less memory. We pay roughly √N more cycles to use √N less RAM. For large computations, this trade-off is the only one that matters — RAM is the wall you hit first, and recovering memory unlocks workloads that conventional provers simply cannot run on commodity hardware.
Where the moat applies
zkVM execution proofs
Long-running programs, many syscalls, complex state. RISC Zero, SP1, and similar systems handle this via continuations — splitting the trace into chunks and recursively aggregating. That works, but it adds:
- Memory pressure on each chunk's prover — still O(chunk size).
- Aggregation overhead — every chunk needs to be re-verified to be folded.
- Operational complexity — orchestrating the chunked prover fleet.
TinyZKP runs the whole trace in a single shot at √N memory. Chunked aggregation becomes optional, not load-bearing.
zkML inference receipts
Proving a neural net forward-pass. Memory usage is dominated by the largest layer's intermediate activations. Conventional STARK provers need RAM proportional to the entire flattened computation graph. TinyZKP's memory usage is proportional to the largest block, not the largest layer or the dataset.
Rollup batch attestation
Sequencers want to batch many transactions. Today, the batch size is bounded by RAM — beyond a few thousand transactions, you need a recursive aggregator. With TinyZKP, the batch size is bounded by time and bandwidth, not memory. A continuously-running prover is feasible on a moderately-sized box.
Cost calculator
Self-host estimate: 1× r6i.8xlarge instance (32 vCPU, 256 GB RAM, ~$1,400/mo committed-use) + ~$2,000/mo blended cost for DevOps, on-call rotation, monitoring. The 16-vCPU tier (~$700/mo) doesn't have enough memory for 10M+ trace steps; you have to step up to a memory-optimized instance the moment a single trace exceeds your RAM cliff. TinyZKP's O(√N) prover doesn't have a cliff.
What you get on the Compute tier
- $0.50 per million trace steps. No monthly base fee. Pay for what you prove.
- Up to 100M-step traces per single proof. Larger workloads → talk to us about Enterprise.
- ≥128-bit soundness. Same security floor as the rest of the platform; no relaxed parameters.
- 100 RPM, 8 inflight jobs. Enough headroom for production zkVM/zkML pipelines.
- 60-minute max prove time per job. Anything longer almost always benefits from proof aggregation; we'll help you architect it.
- Email support, 24-hour response SLA. Your job ID, our triage queue.
The technical claim, defensible in one sentence
TinyZKP is the only production STARK proving service whose prover memory is bounded at O(√N) for arbitrarily large computations — meaning a 100M-step zkVM trace fits on commodity hardware. Every other production STARK system requires O(N) memory — linear in computation size — forcing aggressive segmentation+recursion or simply capping trace size. The whitepaper proves it; the open-source backend ships it; the Compute tier rents it.
Get started
Compute is self-serve from $0/mo + usage. Sign up, paste your API key, prove your first 1M-step trace in under a minute.
Questions on whether TinyZKP fits your workload? Email logan@tinyzkp.com with a paragraph on what you're proving and we'll either shape it together or tell you straight if it's not the right tool.