zkSync's Airbender now measures real proof costs. A market without that data is guesswork.
Tracking predicted versus actual cycle costs sounds like plumbing. At the contract level, it is the pricing data any future prover market needs.
CryptoVibe Desk · zksync · proof-systems · layer-2
- →zkSync shipped core-v31.2.0 and airbender_prover_server-v0.1.1 on July 14, adding cycle tracking that compares predicted and actual proof compute costs.
- →Real cycle data is the base layer for a competitive prover market, where computation gets priced on actual work instead of estimates.
- →Watch for Matter Labs to publish a prover market spec or introduce dynamic proving fees tied to real cycle counts by Jan. 14, 2027.
- Airbender prover → The software that generates cryptographic proofs showing zkSync transactions are valid.
- cycles → A unit of computational work inside a proof. More cycles usually means more time and cost.
- prover market → A system where multiple services generate proofs and compete on price and speed.
- multivm → zkSync's execution environment for running smart contract code and tracking proof work.
zkSync shipped two releases today that change how Airbender accounts for compute work.
This is infrastructure, not a feature launch. The bet is simple: a prover market only works when proof work is measured, compared, and stored. These releases add that measurement.
core-v31.2.0 adds a Cycles Tracer to the multivm, according to Matter Labs' release notes. The tracer records how many computational cycles each proof actually consumes. That is different from what the system predicted before execution. A state_keeper change stores both numbers side by side: the forecast and the real output.
airbender_prover_server-v0.1.1 does the other half. It moves the prover server into its own workspace. It also sends actual guest cycle counts from the prover back to the coordinating server. The verifier is pinned to v29.8.0 in the same release.
You cannot price compute on estimates when the prover and the rollup have different incentives. You need real cycle counts that both sides can inspect. The Cycles Tracer and state_keeper persistence create that base. The engineers know this; the release notes don't linger on it.
Matter Labs has not published a prover market spec. airbender_prover_server at v0.1.1 is early-stage by any read. But instrumentation ships before the market mechanism, not after. Read the PR diff, not the thread.
No external verification of these features exists beyond Matter Labs' releases. If you're building on this stack, test the cycle numbers against your own workloads. Treat the forecasts as provisional for now.
The tradeoff is visibility for simplicity. The old model ran on estimated cycles with no stored comparison. The new model surfaces forecast error. If you're a Starknet or Polygon zkEVM dev, this is worth tracking.
Matter Labs is leaving the market design underspecified while shipping the measurement layer first. That gap matters because cycle data becomes pricing power.
By Jan. 14, 2027, watch for either a published Matter Labs prover market spec or zkSync fees tied to actual cycle counts.
Primary links and supporting reads used by the desk for this story.
Forward this.
