Scaling Lighter: Chasing Real Time Proving

Over the past month, average block proof time on Lighter dropped from ~5.3 minutes to ~1 minute through two independent efforts rolled out on July 23 and August 23. Put simply, Lighter can now verify blocks much faster, increasing capacity, reducing infrastructure costs, and creating more room to scale. These two efforts are:
Heavy/Light decomposition — a business-logic optimization: we changed what gets proven, exploiting the fact that the overwhelming majority of exchange transactions are structurally simple. This halved proving time.
Prover backend optimizations from the Eigen Labs proving contest — pure infrastructure optimizations to the Plonky2 prover: same circuits, same constraints, dramatically faster proving. We are rolling these out in batches; the first went live on August 23 and more than halved proving time again.
A supporting change along the way, on August 10, batched all Schnorr signature verification into a single Plonky3 proof per block — a ~20% improvement (visible as the small middle step in the timeline below).
These are completely orthogonal: Heavy/Light changes which circuit each transaction pays for, while the backend work makes the machinery that proves those circuits faster. Their speedups compound — and the rest of the contest optimizations, still being productionized, are expected to bring another ~2× on top, taking the total to roughly 10× versus mid-July.

In Chasing Microseconds, we described how Lighter's execution and API layers deliver a 55 ms end-to-end p99; this article is about what happens after: every transaction executed on Lighter — orders, liquidations, transfers, deposits, withdrawals — is asynchronously proven with a zero-knowledge proof, each proof extending the previous one into a single valid chain of state transitions. Proving throughput bounds how much sustained load the exchange can prove and settle in reasonable time, and it drives the cost of running the protocol.
Heavy/Light Decomposition: Introducing State Jumps
Transactions are very different in nature: a modified quote needs only a small part of the constraints, while a matching scenario needs a lot of expensive arithmetic for health checks. In a monolithic circuit, every transaction pays the worst case. Measuring the actual distribution showed activity is dominated by market makers maintaining quotes — fewer than 2% of transactions result in a trade.

So we split the transaction circuit in two: a Light circuit covering exactly what the dominant, simple transactions need (nonce and signature checks, order book updates, single-account health checks) and a Heavy circuit — the full circuit — for matching, liquidations, L1 priority operations, transfers, and everything else. Each block is proven as two independent proof chains that are recursively aggregated, together with the block's pre-execution proof, into a single block proof; nothing changed for the upper aggregation layers.

Since light transactions dominate, the average block proves at close to the light circuit's cost:

The technical hardship is that light and heavy transactions are interleaved in execution order, so each chain must jump over segments proven by the other — and a circuit that accepts an arbitrary intermediate state as its new starting point is unsound. Our state-jump protocol makes each chain fold what it proved into a coverage hash chain ("from tx i to j, I turned state root A into B") and what it skipped into a claims hash chain ("I assumed that between j and k, B became C"). At block aggregation the block circuit enforces:

Every transition one chain assumed is exactly a transition the other proved; with unique, sequential transaction indices the two chains must tile the block perfectly — no gaps, no overlaps, no substituted states. The block circuit also pins both chains to the same initial state root and takes the block's output roots from the chain containing the final transaction. The two circuits are proven fully independently at different costs while remaining exactly as sound as a single sequential circuit.
Note what this optimization did not touch: the proving system, the field arithmetic, the hash functions, the prover implementation. It is purely a restructuring of which constraints each transaction pays for — driven by exchange business logic — which is why every subsequent improvement below stacks on top of it.
The Lighter Prover Challenge
The second effort attacked the proving stack itself. Together with @eigenlabs, we ran an open proving contest on @yukonresearch: we published a benchmark harness with a real 500-transaction Lighter block, and anyone could submit optimizations to the Plonky2 prover that made it prove faster on Apple Silicon — with a pinned, trusted verifier ensuring no submission could weaken constraints and still pass. Contestants submitted pull requests against the challenge repository, and the merged optimizations compounded into a dramatic speedup on identical circuits. Our thanks to Eigen Labs for organizing and running the contest, and to every contestant who submitted.
The merged work is being reviewed and productionized in batches. The main areas of improvement are:
Merkle tree and Poseidon2 hashing backend rewrite (~20% of the total time saved): cache-friendly buffer management and vectorized hashing in the prover's hottest loop.
Parallel heavy/light chain recursion workers with NEON Goldilocks field arithmetic (~10%): both proof chains recurse concurrently, on hand-vectorized field ops.
Polynomial arithmetic and FFT optimizations (~10%): faster batch division, twiddle-factor reuse, and higher FRI folding arity.
Packed gate evaluation (~15% across many submissions): specialized constraint-evaluation kernels for the most common gates (range checks, Poseidon2, quintic extension ops) replacing the generic evaluator.
Metal GPU offload: parts of Merkle hashing and FRI moved onto Apple Silicon's GPU, differentially tested against the CPU path.
The first batch went live on August 23 and cut median block proof time per machine from ~133 s to ~59 s, uniform across all three Mac mini fleets — with the remaining work expected to halve it once more:

What Changed in Production
Lighter's primary proving layer is a fleet of Apple Silicon Mac minis — high single-core performance, high memory bandwidth, roughly half the cost per proven transaction of cloud ARM instances — backed by an elastic cloud overflow layer. In mid-July the overflow layer fired daily, often running thousands of tasks for hours, and the proving backlog oscillated between 10k–80k transactions. Each rollout raised the same fleet's sustained capacity — to the point that it now clears comfortably more than the highest load ever observed — while overflow usage collapsed to rare short bursts and the backlog now idles in the low thousands.


For traders this shows up as withdrawal finality: withdrawals finalize when their block's proof settles to L1, so withdrawal lag blows up when load outruns the provers. That threshold has more than quadrupled since mid-July, and the quiet-period floor dropped from ~21–22 minutes to ~16–17 minutes after Heavy/Light and keeps falling with proof times. The p99 of withdrawal latency belongs to the provers, and this work was for the p99.
Summary & What’s Next
The remaining contest optimizations, combined with our own scheduling improvements, deliver another significant speedup. In testing, a 500-transaction block that took ~187s on the pre-contest production code now proves in under 30s. These improvements are going through the same review and rollout process.

Two orthogonal levers — proving less per transaction, and proving it faster — already compound to better than 5×, and 10× is within reach as the remaining optimizations roll out.
What This Means for Traders
Traders don't feel proof time; they feel how long a withdrawal takes to finalize on L1. That delay is a baseline (how long a block takes to prove and aggregate) plus a queue that forms whenever volume outruns the provers. The fleet has always been elastic, adding on-demand machines as the backlog grows, but spinning them up is not instant, so during sharp volume spikes withdrawal latency could rise above its ~21 minute floor until overflow caught up.

With the base fleet's sustained capacity now well above the highest load ever observed, spikes are absorbed without waiting for overflow at all, so the queue stays near zero and withdrawal time holds at the baseline. Faster proofs then lower that baseline too, from ~21–22 minutes to ~16–17 minutes today, with more to come. Finality is both lower and, more importantly, the same during a volatility spike as during a quiet market.

We look forward to sharing more of the technical advancements we’re making across our infrastructure. We’ll also announce the winners of the Lighter Proving Contest in the next few days.

Scaling Lighter: Chasing Real Time Proving

Over the past month, average block proof time on Lighter dropped from ~5.3 minutes to ~1 minute through two independent efforts rolled out on July 23 and August 23. Put simply, Lighter can now verify blocks much faster, increasing capacity, reducing infrastructure costs, and creating more room to scale. These two efforts are:
Heavy/Light decomposition — a business-logic optimization: we changed what gets proven, exploiting the fact that the overwhelming majority of exchange transactions are structurally simple. This halved proving time.
Prover backend optimizations from the Eigen Labs proving contest — pure infrastructure optimizations to the Plonky2 prover: same circuits, same constraints, dramatically faster proving. We are rolling these out in batches; the first went live on August 23 and more than halved proving time again.
A supporting change along the way, on August 10, batched all Schnorr signature verification into a single Plonky3 proof per block — a ~20% improvement (visible as the small middle step in the timeline below).
These are completely orthogonal: Heavy/Light changes which circuit each transaction pays for, while the backend work makes the machinery that proves those circuits faster. Their speedups compound — and the rest of the contest optimizations, still being productionized, are expected to bring another ~2× on top, taking the total to roughly 10× versus mid-July.

In Chasing Microseconds, we described how Lighter's execution and API layers deliver a 55 ms end-to-end p99; this article is about what happens after: every transaction executed on Lighter — orders, liquidations, transfers, deposits, withdrawals — is asynchronously proven with a zero-knowledge proof, each proof extending the previous one into a single valid chain of state transitions. Proving throughput bounds how much sustained load the exchange can prove and settle in reasonable time, and it drives the cost of running the protocol.
Heavy/Light Decomposition: Introducing State Jumps
Transactions are very different in nature: a modified quote needs only a small part of the constraints, while a matching scenario needs a lot of expensive arithmetic for health checks. In a monolithic circuit, every transaction pays the worst case. Measuring the actual distribution showed activity is dominated by market makers maintaining quotes — fewer than 2% of transactions result in a trade.

So we split the transaction circuit in two: a Light circuit covering exactly what the dominant, simple transactions need (nonce and signature checks, order book updates, single-account health checks) and a Heavy circuit — the full circuit — for matching, liquidations, L1 priority operations, transfers, and everything else. Each block is proven as two independent proof chains that are recursively aggregated, together with the block's pre-execution proof, into a single block proof; nothing changed for the upper aggregation layers.

Since light transactions dominate, the average block proves at close to the light circuit's cost:

The technical hardship is that light and heavy transactions are interleaved in execution order, so each chain must jump over segments proven by the other — and a circuit that accepts an arbitrary intermediate state as its new starting point is unsound. Our state-jump protocol makes each chain fold what it proved into a coverage hash chain ("from tx i to j, I turned state root A into B") and what it skipped into a claims hash chain ("I assumed that between j and k, B became C"). At block aggregation the block circuit enforces:

Every transition one chain assumed is exactly a transition the other proved; with unique, sequential transaction indices the two chains must tile the block perfectly — no gaps, no overlaps, no substituted states. The block circuit also pins both chains to the same initial state root and takes the block's output roots from the chain containing the final transaction. The two circuits are proven fully independently at different costs while remaining exactly as sound as a single sequential circuit.
Note what this optimization did not touch: the proving system, the field arithmetic, the hash functions, the prover implementation. It is purely a restructuring of which constraints each transaction pays for — driven by exchange business logic — which is why every subsequent improvement below stacks on top of it.
The Lighter Prover Challenge
The second effort attacked the proving stack itself. Together with @eigenlabs, we ran an open proving contest on @yukonresearch: we published a benchmark harness with a real 500-transaction Lighter block, and anyone could submit optimizations to the Plonky2 prover that made it prove faster on Apple Silicon — with a pinned, trusted verifier ensuring no submission could weaken constraints and still pass. Contestants submitted pull requests against the challenge repository, and the merged optimizations compounded into a dramatic speedup on identical circuits. Our thanks to Eigen Labs for organizing and running the contest, and to every contestant who submitted.
The merged work is being reviewed and productionized in batches. The main areas of improvement are:
Merkle tree and Poseidon2 hashing backend rewrite (~20% of the total time saved): cache-friendly buffer management and vectorized hashing in the prover's hottest loop.
Parallel heavy/light chain recursion workers with NEON Goldilocks field arithmetic (~10%): both proof chains recurse concurrently, on hand-vectorized field ops.
Polynomial arithmetic and FFT optimizations (~10%): faster batch division, twiddle-factor reuse, and higher FRI folding arity.
Packed gate evaluation (~15% across many submissions): specialized constraint-evaluation kernels for the most common gates (range checks, Poseidon2, quintic extension ops) replacing the generic evaluator.
Metal GPU offload: parts of Merkle hashing and FRI moved onto Apple Silicon's GPU, differentially tested against the CPU path.
The first batch went live on August 23 and cut median block proof time per machine from ~133 s to ~59 s, uniform across all three Mac mini fleets — with the remaining work expected to halve it once more:

What Changed in Production
Lighter's primary proving layer is a fleet of Apple Silicon Mac minis — high single-core performance, high memory bandwidth, roughly half the cost per proven transaction of cloud ARM instances — backed by an elastic cloud overflow layer. In mid-July the overflow layer fired daily, often running thousands of tasks for hours, and the proving backlog oscillated between 10k–80k transactions. Each rollout raised the same fleet's sustained capacity — to the point that it now clears comfortably more than the highest load ever observed — while overflow usage collapsed to rare short bursts and the backlog now idles in the low thousands.


For traders this shows up as withdrawal finality: withdrawals finalize when their block's proof settles to L1, so withdrawal lag blows up when load outruns the provers. That threshold has more than quadrupled since mid-July, and the quiet-period floor dropped from ~21–22 minutes to ~16–17 minutes after Heavy/Light and keeps falling with proof times. The p99 of withdrawal latency belongs to the provers, and this work was for the p99.
Summary & What’s Next
The remaining contest optimizations, combined with our own scheduling improvements, deliver another significant speedup. In testing, a 500-transaction block that took ~187s on the pre-contest production code now proves in under 30s. These improvements are going through the same review and rollout process.

Two orthogonal levers — proving less per transaction, and proving it faster — already compound to better than 5×, and 10× is within reach as the remaining optimizations roll out.
What This Means for Traders
Traders don't feel proof time; they feel how long a withdrawal takes to finalize on L1. That delay is a baseline (how long a block takes to prove and aggregate) plus a queue that forms whenever volume outruns the provers. The fleet has always been elastic, adding on-demand machines as the backlog grows, but spinning them up is not instant, so during sharp volume spikes withdrawal latency could rise above its ~21 minute floor until overflow caught up.

With the base fleet's sustained capacity now well above the highest load ever observed, spikes are absorbed without waiting for overflow at all, so the queue stays near zero and withdrawal time holds at the baseline. Faster proofs then lower that baseline too, from ~21–22 minutes to ~16–17 minutes today, with more to come. Finality is both lower and, more importantly, the same during a volatility spike as during a quiet market.

We look forward to sharing more of the technical advancements we’re making across our infrastructure. We’ll also announce the winners of the Lighter Proving Contest in the next few days.

Source:https://twitter.com/lighter_xyz/status/2092356573049860259