Benchmark results

This page summarizes the controlled measurements behind the design and evaluation paper (arXiv link to follow) and the repository's benchmark notes. Use it to estimate what StateSync-GKR changes for memory, repeated requests and serving, and read each result together with its comparison table.

Results at a glance#

For a visual overview, see StateSync-GKR performance.

Memory with sparse layer reduction#

The production prover uses a Libra-style two-phase sparse oracle. It keeps input-sized buffers and a sparse list of multiplication gates instead of quadratic input-pair tables. What you gain is room for a wider circuit or more concurrent proof jobs within the same RAM budget.

Requested allocation is 3,242.41 times lower and whole-process RSS is 89.46 times lower. The two ratios cover different ownership intervals and cannot be substituted for each other. Allocator counters and stage observation stay inside both prover timers and are not subtracted. JSON construction, hashing and verification run after the timer but remain inside process RSS.

The Dense reference is a test-only part of StateSync-GKR, so the result measures a representation change inside one engine, on a generic two-layer circuit, for one job on CPU 0. Plonky3 supplies field, hash and challenger code to both modes and is not a comparison target, and no external GKR implementation is involved. The ratio does not predict the memory reduction for a production sparse-Merkle circuit, and a single pinned job says nothing about 48-core throughput.

Memory limits and tested scale#

A separate study on an isolated development host ran Sparse and Dense under explicit memory limits. It preserved 17 attempts: 14 successes, one address-space allocation abort and two native out-of-memory kills. Concurrent jobs share one generic circuit and witness while each keeps its own oracle and proof state.

Width 65,536 is the largest width tested. It bounds the evidence without defining a supported maximum.

Prepared verification with derived wiring#

Derived wiring evaluates regular gate families in closed form and keeps an exact sparse residue for the rest. It lowers the repeated work of checking a prepared circuit's connections while the proof stays the same.

Table/Derived time ratio (higher means derived wiring is faster):

TableWiring already iterates a sparse gate list and is unrelated to the quadratic Dense prover reference in the memory comparison. Both wiring evaluators are part of StateSync-GKR. The verifier still recomputes native leaf and path hashes from the private witness, and that work stays inside both timers.

Preparation reuse#

PreparedSync holds the compiled circuit, its full circuit commitment and the derived wiring for one operation kind and configuration. Reusing it removes per-request compilation and commitment work. Each request still has its own witness, transcript and proof.

Direct calls show where the setup cost sits. These are medians of five run-specific request p50 values for depth-24 membership, with 300 measured requests and five warmups per process. They are separate direct measurements; for the end-to-end comparison, use the fresh/prepared ratios above.

Complete local batch with parallel output#

Parallelizing the output stages, encoding and encoded verification, lowered the time of the complete prepared local batch. Both policies already parallelize witness generation and proving.

The ratio comes from paired interval ratios, so it can differ from the quotient of the two throughput columns. Each throughput value is the median of five process rates, and each process rate is 768 divided by the median of ten complete-pipeline intervals after one warmup batch. In the same study, smaller batches and runs with 48 workers produced smaller ratios.

Proof size across tree depth#

Cube gates with affine fusion represent a Poseidon2 round in one layer, and Merkle path compressions are checked as parallel constraints. As a result, the compiler produces 118 layers in all nine measured profiles: membership, non-membership and update at depths 24, 28 and 32.

Circuit width, witness work and total computation still grow with depth, so the compact schedule limits proof growth without making the work constant. Cube and affine fusion has no separately measured speed multiplier.

CPU throughput#

These rates measure inner proof jobs on one large host. They show how much prepared work the engine completes in parallel.

The parallel-witness column is orchestration in the benchmark caller around the public APIs; the facade has no built-in witness-parallel method. These are inner-job computation rates. For end-to-end serving, see the serving results below, which add queueing and transport but still exclude state commits.

Serving through full-proof acceptance#

The serving studies send complete encoded proofs over private TCP to a separate 16-core frontend. A request counts as served only when the frontend's strict encoded verifier accepts it against the original request, so queueing and transport are inside the measured latency.

48 cores for 15 minutes#

Minute-level mean pending counts stayed around 48 to 49 during the run. The result covers this 15-minute window and makes no availability guarantee beyond it.

Two 48-core workers against one 96-core worker#

This comparison holds total worker resources at 96 cores and 192 GiB and uses the same frontend and 5-ms wait. Each policy ran three 20-second processes at 1,000 requests/s in total.

Each policy has its own batch cap, so this compares deployment policies as a whole. The result supports the two-worker policy at this load and period. It says nothing about other 96-core settings or about stability over 15 minutes.

192 cores at 1,000 and 1,150 requests per second#

At 1,000 requests/s, three 60-second runs accepted all 180,000 timed requests within one second. Process p99 values were 426.032, 438.775 and 443.471 ms, and 99.9183%, 99.7167% and 99.6217% of requests were accepted within 500 ms. Mean worker use was about 64.57 to 65.24 of the 192 available core equivalents.

At 1,150 requests/s, one 60-second input window produced these results:

Three earlier 15-second screens at 1,150 requests/s met one second for every timed request; the 60-second confirmation did not. The 20,447 requests above one second were all accepted later; none was rejected or lost. Because the queue grew during the window, the run establishes the finite-window result above and leaves sustained capacity at 1,150 requests/s unmeasured. Sixty seconds is the length of the input window, and the prover remains usable after it.

Most of the added delay occurred before computation began. Server pre-compute wait had p99 1,367.973 ms at 1,150 requests/s, against 343.967–354.871 ms in the 1,000 requests/s confirmations, while mean worker use was 78.09 core equivalents. The serving caller processes one batch at a time and finishes hashing, framing, writing and logging each result before it starts the next batch, so the caller's return path matters alongside the prover.

Tuning observations on 48 cores#

A fine-grained study on the 48-core VM tested 19 conditions with three processes each across worker count, batch cap, wait, rate and operation mix.

• Of 456,750 timed offers, 451,429 were accepted and 5,321 received explicit server-run-limit refusals. The refusals occurred at batch cap 16 with 500 requests/s and at batch cap 48 with 1,000 requests/s, when the 30-second run limit left jobs uncomputed, and they stay in the success denominators.
• At a balanced 500 requests/s, 32 workers had p99 latency around 4.56 to 4.66 s.
• Worker counts of 36 to 40 and a batch cap of 40 kept every timed request below 500 ms in 15-second repetitions. Treat them as short-run candidates measured on the 48-core VM; a smaller VM needs its own measurement.
• An update-only load at 500 requests/s did not meet one second in every process, so the balanced result does not transfer to every operation mix.

To apply these observations to your own deployment, see Performance tuning.