Airbender Prime Puts the Slowest Blocks in Focus

Analysis | October 17, 2026

ZKsync’s October 13 evaluation reports each of 7,200 sampled blocks proved in under 12 seconds on one GPU.

The useful engineering question is what to do with a faster prover's headroom. Open Market Notes examines three choices: shorten waiting, absorb bursts, or require additional implementations to agree. The calculations below are original hypothetical examples, not measurements of Airbender Prime or an independent reproduction of the announced test.

Decide where the clock stops

Ethereum’s roadmap describes a 12-second block cadence and distinguishes proof generation from verification.

For our proposed service test, start the clock when a complete job becomes available and stop it when the required result has been accepted. Record queueing, proving, delivery and verification separately. A shorter proving stage leaves room for the others, but does not establish how much time they actually consume. A block interval alone also does not specify the service's acceptance deadline; that must be stated explicitly.

One slow job can delay its neighbor

Consider five independent jobs arriving at seconds 0, 12, 24, 36 and 48. One worker serves them in arrival order, without interruption. Their processing times are 8, 8, 20, 8 and 8 seconds. Each deadline is 12 seconds after arrival. Ignore transport, verification, startup and all other costs; finishing exactly at the deadline counts as on time.

The completion times are 8, 20, 44, 52 and 60 seconds, against deadlines of 12, 24, 36, 48 and 60. The third and fourth jobs are late, although average processing time is only 10.4 seconds. The fourth job needs just eight seconds of work, but inherits a wait from the third. The fifth meets its deadline with no margin for an omitted cost.

This example does not estimate a real system's miss rate. It isolates the distinction between time spent processing a job and time elapsed since that job arrived. Reordering jobs, allowing interruption or adding workers would create a different experiment. Those choices should be visible rather than buried inside an average.

Spare capacity and required agreement differ

Ethereum Foundation research advocates diversity in both zkVMs and the state-transition implementations they execute.

Now consider two explicitly hypothetical acceptance rules. One accepts the first valid result from two workers. The other requires valid, agreeing results from both specified independent implementations. Assume the same candidate block, results available at eight and thirteen seconds, and no other costs. The first rule accepts at eight seconds; the second cannot accept before thirteen. These are illustrative service policies, not a description of current Ethereum consensus.

The extra worker therefore has different jobs in the two designs. In one, it can cover a delayed result; in the other, its result is part of the requirement. More machines alone does not describe what must agree. Any speed comparison should keep the acceptance rule visible, including whether a missing required result leaves the job unfinished.

Test the burst, then disclose the unfinished work

We propose replaying a fixed block sequence under specified arrival schedules, including bursts. Preserve queue history rather than resetting the worker before every block. State available hardware, scheduling rules, the deadline and the acceptance condition. Run the same sequence with the intended redundancy or implementation-diversity requirement enabled.

Report accepted results by the deadline, late results and unfinished jobs separately. Show how long the queue takes to recover after a burst. Do not discard unfinished work merely because it lacks a completion time: excluding it can make a struggling service appear faster. Keep this operational result separate from any security assessment.

The design choice is how to spend the saved time. A shorter wait, a reserve for an awkward sequence and an additional required result are different uses of the same headroom. A useful next demonstration would make that allocation explicit and show whether the chosen deadline survives the queue it creates.