igneum/docs/benchmarks/proving-e2e.md

End-to-end proving benchmark standard

Version 0.1, 3 October 2026. This standard replaces the "a 12 GB card proves one shard in about 20 s" gate (litepaper Proving, roadmap phase 2, spec 5.1). It is the phase 2 pass mark and the published measurement the prover customer brief points at. Nothing in it has been run. Status: designed.

1. Why the shard gate was the wrong gate

A per-shard time is met by shrinking the shard. The shard planner cuts a segment at transaction boundaries so each shard's proving cost is at most S_p (docs/design/execution-layer.md 5.1). S_p is the project's own number. Halve it and every shard proves twice as fast, the 20-second mark is passed, and nothing about the chain's capacity has changed: there are twice as many shards, twice the aggregation work, twice the witness traffic, and the per-shard fixed costs (program load, witness fetch, proof emission) are paid twice. The backlog, which is what a user and a customer feel, can grow while the gate reads green.

The trap is shrinking the shard. The standard below prevents it by fixing the unit of measurement outside the planner's reach: a whole published block, proven end to end, from the moment a prover sees the job to the moment a full node accepts the proof. The planner's choice of S_p is inside the measurement. A smaller shard that helps shows up as a shorter end-to-end time and a flat backlog; a smaller shard that only moves cost shows up as the same time and a rising backlog.

2. Fixed published workloads

Three workloads, published as files under tools/bench-e2e/workloads/ with a genesis state, a transaction list and a SHA-256 of both, so every operator proves the identical bytes. The files do not exist yet; the execution engineer writes them with the phase 2 implementation. Each workload is one chain block's segment.

Id	Workload	Content	Why this one
W1	Transfers	200 simple IGN transfers between 200 pre-funded accounts: 21,000 gas each, 4,200,000 gas total, 200 pgas each at the prototype table (40,000 pgas, to be re-stated at calibration)	The cheapest block to prove per transaction. Sets the floor of fixed cost per shard and per proof
W2	Contract calls with keccak	20 calls to a published contract: each call runs the hashLoop pattern of tools/evm-smoke at 200 iterations (98,900 gas estimated with the fold on the v3 simnet) plus one storage write with an event; about 2,000,000 gas, pgas from the calibrated table	Keccak is the opcode a zkVM pays most for relative to native execution. This block is the one a per-transaction gate would hide
W3	Full budget	A block whose proving cost is exactly the consensus proving-cost budget B_p: the W2 call repeated until the planner refuses the next one, padded with W1 transfers to the gas limit	The worst block the chain can accept. If W3 cannot be sustained, the budget is wrong, not the gate

Rules for the workloads:

1. The genesis state and the transaction bytes are frozen with the proof-system version. A new ProofSystem version (design 5.6) republishes all three with new hashes; results under one version are never compared with results under another.
2. B_p is set from this benchmark, not the other way round. The first run uses the provisional B_p of the phase 2 implementation; W3 is regenerated when B_p changes and the standard records the value used.
3. Nobody tunes the planner against the workloads. The planner's parameters (S_p, the shard count rule) are fixed in the release before the run and published with it.

3. The measured path

The clock starts when a prover's client receives the job and stops when a full node that did not produce the proof accepts the proof record. Every stage is timestamped by the prover and the verifying node, and every stage is reported, because an operator who proves fast but queues slow is not sustaining anything.

Stage	Starts	Ends	Who stamps it
Queueing	Job received (shard assignment seen, or segment executed for an open shard)	A card starts on it	Prover client
Transfer	Witness request sent	Witness bytes complete and checked against the segment hash	Prover client
Proving	Card starts	Shard proof emitted	Prover client
Aggregation	First shard proof of the segment available	Segment proof emitted (recursion over the shards and the previous segment proof)	Aggregating client
Verification	Proof record gossiped	A non-producing full node verifies it and the native-execution veto passes (design 5.5)	The verifying node
End to end	Job received	Accepted	Both; the difference of the two wall clocks is reported with the clock-sync method used

The wrapped proof (Groth16 or Plonk over bn254, design 5.3) is a fourth stage measured separately for the bridge and light-client case (O-10.7). It is not in the end-to-end figure for the chain, because the chain accepts the segment proof.

4. Reported figures

Per workload, per hardware configuration, from a continuous 2-hour run in which the workload is issued at the chain's block rate (one segment per second at launch) so that the provers must keep up, not catch up.

Figure	Definition
Median	The 50th percentile of end-to-end time over the run
Slowest 5%	The 95th percentile
Slowest 1%	The 99th percentile
Per-stage medians	Queueing, transfer, proving, aggregation, verification, each at p50 and p99
Failure rate	Jobs whose proof was never accepted, divided by jobs issued. A failure is counted whether the cause was a crash, an out-of-memory, a bad proof or a timeout
Retry rate	Jobs proven more than once by the same operator before acceptance, divided by jobs issued
Backlog	Shards issued and not yet accepted, sampled every 10 s for the 2 hours, reported as the series, its maximum, and the slope of a least-squares line through the second hour. A slope above zero is a growing backlog
Throughput	Segments accepted per second over the second hour, against the issue rate

A run is reported whole or not at all. A run that is stopped early is reported as a failure with the time it stopped.

5. Full cost per proof

Cost is reported per accepted segment proof, in dollars, with each input stated so that a reader can substitute their own tariff. Nothing is netted against rewards; this is cost only.

Component	How it is computed	Stated inputs
Electricity	Card and host power at the wall, measured with a meter over the run, times the tariff, divided by accepted proofs	The tariff. The standard reports two: $0.12 per kWh and $0.30 per kWh, chosen as a low and a high domestic rate, approximate. The operator also reports their own
Host amortisation	Purchase price of the card and the host it needs, divided by an assumed life of 3 years at 24 hours a day, times the run's hours, divided by accepted proofs	Purchase price (a receipt or a listing on the run date) and the 3-year life
Bandwidth	Witness bytes in plus proof bytes out, times a per-gigabyte price, divided by accepted proofs	The per-gigabyte price. The standard reports $0.01 per GB and $0.10 per GB, approximate; a metered residential line reports its own
Failed work	Electricity and amortisation spent on jobs that were not accepted (failures, retries, work superseded by a faster prover), spread over the accepted proofs	Counted from the same logs; nothing extra
Total	The sum of the four, at both tariffs and both bandwidth prices, as a range

The cost of a 20% pool share or an external job fee does not appear here. Those are revenue and belong in docs/analysis/security-budget.md and docs/design/payment-routes.md.

6. Eligible consumer cards

Mining compatibility and proving compatibility are reported separately, because they are different workloads: mining is the random-access lottery hash (bench-log), proving is the zkVM. A card can be in one column and not the other.

Card	Memory	Mining: lottery hash	Proving: this standard
NVIDIA RTX 5090	32 GB	Measured: 229 Mhash/s at 1 GiB, bit-exact (bench-log, 3 October 2026)	Not run
NVIDIA RTX 4090	24 GB	Not run	Not run
NVIDIA RTX 4070	12 GB	Not run	Not run; the design's reference card class ("a 12 GB card")
NVIDIA RTX 3060 12 GB	12 GB	Not run	Not run; the phase 2 gate names a "3060-class card" (ledger P1)
NVIDIA RTX 3080	10 GB	Not run	Not run; below the 12 GB design floor, listed to measure the floor
AMD RX 7900 XTX	24 GB	Not run (discrete AMD never run, O-1.15)	Not run
AMD RX 6700 XT	12 GB	Not run	Not run
AMD gfx1036 (Ryzen 7 9800X3D integrated)	shared	Measured: 4.38 Mhash/s on 1 compute unit, bit-exact (bench-log)	Not eligible: shared system memory
Apple M5 Max (40 GPU cores)	64 GB unified	Measured: 45.2 Mhash/s at 1 GiB, bit-exact (bench-log)	Not run
Apple M-series, 16 GB unified	16 GB unified	Not run	Not run
Intel Arc A770	16 GB	Not run	Not run

A card enters the eligible list for proving when three unrelated operators (section 8) have sustained W1, W2 and W3 on it with a flat backlog. Until then the list is a list of candidates, and the litepaper's "12 GB or more proves full shards" is a design target.

7. The acceptance standard

Verbatim, the pass mark for phase 2:

At a declared workload and hardware configuration, independent operators can sustain the advertised throughput without a growing proof backlog.

Applied to this standard:

Term	Meaning here
Declared workload	W1, W2 or W3 by hash, under a named proof-system version
Declared hardware configuration	Card model, card count per host, host CPU and RAM, driver and toolchain versions, as a published fingerprint
Advertised throughput	The issue rate of the run: one segment per second at launch. The project advertises no higher rate than the one sustained in the published runs
Independent operators	Three unrelated operators as defined in section 8, each sustaining it on their own run
Sustain	The full 2-hour run with a failure rate under 1% and a slowest-1% end-to-end time under the proof lag the litepaper states (60 s at launch)
Without a growing proof backlog	The second-hour backlog slope is at or below zero and the maximum backlog is under 60 segments

A pass is per workload and per configuration. "Phase 2 passed" means W1, W2 and W3 all passed on at least one consumer configuration from section 6 with at most one card per host. A pass on a multi-card host or a datacentre card is reported but does not pass the phase, because the chain's claim is consumer hardware.

8. Reproduction protocol

8.1 What counts as unrelated

Three operators are unrelated when every row holds for every pair:

Test	Requirement
Person	Different natural or legal persons; none is the project, an agent of it, or paid by it for the run (a published fixed reproduction reward, equal for everyone and announced before the run, is allowed and disclosed)
Hardware	Bought separately; no shared host, card, rack or power meter
Network	Different autonomous systems, verified by the IP in the published logs; not the same residential ISP account
Location	Different physical sites
Software	The same published release by hash; nobody receives a private build
Money	No payment, loan or equipment between them or from the project, beyond the disclosed reproduction reward

An operator declares each row in their report and signs it with the vote key that mined on the devnet under the same fingerprint, so a report is tied to a key with a history.

8.2 Steps

1. The project publishes: the release (binary hashes, source tag), the three workload files with hashes, the run script tools/bench-e2e/run.sh, the report format, the proof-system version, B_p and S_p, and the date range.
2. Each operator runs the 2-hour run for each workload on their configuration, with a wall-power meter and NTP-disciplined clocks, and keeps raw logs.
3. Each operator publishes the report (section 4 figures, section 5 costs, the hardware fingerprint, the declarations of 8.1) and the raw logs, signed.
4. The project publishes all reports unedited, pass or fail, next to its own run, on the bench page, and links each from docs/evidence.md row 15 and row 16. A failing run is as public as a passing one.
5. The eligible list (section 6) and the phase gate (section 7) are updated from the published reports only.

8.3 What the project may not do

• Change S_p, B_p, the planner or the workloads between the announcement and the end of the date range.
• Pick which reports to publish.
• Count its own run as one of the three.
• Advertise a throughput higher than the lowest of the three passing runs.

9. Open items

Item	What closes it
The workload files and tools/bench-e2e/	Written with the phase 2 SP1 implementation (execution engineer)
The provisional B_p and S_p	The project's own first run, published before the external runs
The wrapped-proof stage on consumer hardware	O-10.7, measured in the same campaign
The reproduction reward and who pays it	docs/plans/funding.md, challenge reward row
Whether a 10 GB card can prove W3 at all	The RTX 3080 row of section 6