Hi everyone,
We built a prototype to see what it would take for a Zcash node to verify a STARK proof for an L2 batch. We wanted to measure the cost to the node and identify what a future transaction format would need to specify.
STARK verification through Transparent Zcash Extensions (TZEs) was considered for NU7. The Zcash Foundation’s polling recap found insufficient support for including it and called for further discussion of the use case and design. NU7 shipped without a new transaction format. We ran our experiment on a separate local Regtest network with Zebra v7, NU7 rules, and an experimental transaction extension. NU7 polling recap · NU7 deployment specification
What ran on Regtest
We built a Rust verifier and integrated it into Zebra. A small Cairo token ledger uses the extension to submit batches. Each accepted batch spends the output that records the previous ledger state and creates a new one. Both nodes check the Stwo proof before accepting the transition.
In two full test runs, both nodes accepted six chained batches per run. We tested deposit claims, L2 transfers, withdrawals, re-proving a batch after a reorg, and continuing after a node restarted from finalized state.
The 4:45 demo follows four batches. With the sequencer stopped, we rebuild the ledger from on-chain data, generate a withdrawal proof, and mine the transaction. Zebra also rejects two variants before accepting the valid transaction. One has a single bit flipped in the proof. The other pays one zatoshi below the prototype’s fee threshold. Watch the Regtest demo
What we measured
Metric
Result
Proof size in the Zebra demo
263,812 bytes
Single-core verification on Apple M4 for proofs of that size
39.5–40.3 ms
Single-core verification on AMD EPYC for proofs of that size
100.6–101.2 ms
Verification cost across the measured parameter sets
About 5–12 Orchard action equivalents
Transactions fitting in a 2 MB block under the measured layouts
About 7–13, depending on proof size
The lab benchmarks use prebuilt inputs and exclude transaction parsing and txid computation. The Orchard/Ironwood baseline is a proxy for Zebra’s batch verification path. Under these measured workloads, block space ran out before verification time did. The prototype charges 13 units per demo proof against its experimental version of the ZIP 218 block budget. We measured the production circuit at roughly 96-bit soundness. Measuring the cost of higher-security parameters on that circuit remains open. The benchmark package includes the recorded inputs and a Python script that reproduces the budget and fee tables. ZIP 218 · Benchmark package and reproduction instructions
What the prototype exposes
Participants in the earlier TZE discussion raised concerns about steering Zcash users toward a transparent L2. Our demo makes the trade-off concrete. Deposit and withdrawal addresses and amounts are visible. We also publish L2 account updates, including balances, so anyone can reconstruct the ledger from the chain. The STARK proof establishes that each update follows the ledger rules. Anyone can read the published data. Withdrawing while the sequencer is offline still requires access to a prover and a miner willing to include the transaction. Earlier TZE privacy discussion
We’d appreciate feedback on three questions.
- What privacy properties should a Zcash-connected L2 meet? How could users recover their funds without publishing account balances?
- Would sharing the ZIP 218 block budget be a sensible way to account for STARK verification? What should we measure under sustained invalid-proof traffic and concurrent verification?
- For a future transaction format such as ZIP 248, which transaction fields should the proof commit to, and how should the specification define that commitment? ZIP 248 draft