STARK verification as a Transparent Zcash Extension (TZE), i.e enabler for a Starknet‑style L2 on Zcash

Governance
1

STARK verification as a Transparent Zcash Extension (TZE), i.e enabler for a Starknet‑style L2 on Zcash

DRAFT BIP PULL REQUEST

Hey ZCash fam, greeting from StarkWare. I am Abdel. I personally like the vibes of the ZCash community. Cyperpunk ethos and freedom tech is the way.
And privacy is normal and is a fundamental right. I am glad that the recent surge of interest on ZCash project has sparked a strong interest for privacy in the whole space. This is very relieving. I wanted to share a proposal to the community, as I believe that our tech can actually be complementary to ZCash. I think there are some cool options to explore together.

TL;DR

I’m proposing a Transparent Zcash Extension (TZE) that verifies a bounded‑size STARK proof within Zcash consensus. The intent is to make Zcash a credible base layer for a Starknet‑style L2: account abstraction, a Cairo VM execution environment (i.e., full programmability on L2), and high throughput with very low per‑tx L2 fees, while keeping L1 privacy exactly as it is today.

Concretely, this would define a TZE type “STARK_VERIFY” with two modes:

  • Mode 1 — Stone (vanilla FRI STARK): a pinned Stone verifier/format (C++) with explicit parameter bounds.
  • Mode 2 — Stwo (Circle STARK): a pinned Stwo verifier/format (Rust) with explicit parameter bounds. (Stwo is newer and faster, but not as battle tested as Stone.)

This is intentionally narrow: verify a proof + public inputs under strict limits; no changes to shielded pools, and no new scripting language. It plugs into the TZE framework (ZIP‑222), which already defines how to add new transparent preconditions and witnesses to transactions.

Dislaimer: I am working at StarkWare, the company building and operating Starknet. This is my own initiative and not instructed by my company. I believe it’s an interesting discussion to raise in the ZCash technical community. Also, before working on this proposal, I was actively working on an OP_STARK_VERIFY proposal for Bitcoin. Still planning to publish it, and the Bitcoin proposal work was prior to the current one.

Why Zcash community should consider this

  • Programmability & scale live on L2, privacy stays on L1. Zcash already has strong base‑layer privacy. What it lacks is a general‑purpose execution environment and cheap throughput. A Starknet‑style L2 (Cairo VM) provides programmability and scale, while Zcash L1 keeps doing what it does best: finality and private custody.
  • Clean integration surface. Using TZE avoids entangling this work with shielded protocols or Bitcoin‑style Script. ZIP‑222 was created precisely to add well‑specified “transparent preconditions” with consensus verification.
  • Hash‑based, transparent assumptions. STARK verification relies mainly on the collision/preimage resistance of transcript/Merkle hashes and the soundness of the polynomial IOP; this is widely regarded as post‑quantum‑plausible (subject to the hash we pin).
  • Reasonable verification cost & static pricing. STARK verification is polylogarithmic in trace size and dominated by hashing (Merkle/FRI). Proof sizes are typically few hundred kilobytes, i.e., heavier than pairing SNARKs (but with better scaling properties, quantum resistance, simpler cryptography and other advantages) but workable if bounded and priced by bytes.

What this enables (if adopted)

  • A Starknet‑style L2 on Zcash:

    • Account abstraction via Cairo contracts;
    • Turing‑complete VM & full expressivity on L2;
    • High throughput and cheap L2 transactions;
    • L1 enforces L2 state transitions by verifying STARK proofs that the L2 operator posts (or that rollup participants aggregate).
      (This mirrors how Starknet posts proofs to L1; here the L1 would be Zcash.)

  • Programmable bridges and assets: Combine with future ZSA work to mint/burn L2‑tracked assets with L1 settlement, or to move value between shielded addresses and an L2 account space via well‑defined preconditions.

Proposal overview (TZE‑style, not an opcode)

This proposal defines a new TZE type = STARK_VERIFY with two modes:

  • mode = 1: Stone (vanilla FRI STARK) — pinned format/params.
  • mode = 2: Stwo (Circle STARK) — pinned format/params.

Per ZIP‑222, each TZE has a (type, mode) and a precondition (challenge) plus witness (evidence). The consensus rule is: for each TZE input, run the extension’s tze_verify(mode, precondition, witness, context) and it must return true.

Precondition / witness layout (high‑level)

  • Precondition (prefix‑free encoding within this (type, mode)):

    • verifier_id (u16): selects a pinned parameter set (field(s), transcript/Merkle hash, FRI expansion, max queries, grinding bits cap, exact wire format version, endianness).
    • pub_in (byte string): public inputs to the statement being proved (e.g., current L2 state root, new state root, and commitments to any data required by the verifier).
    • Optionally a standard context digest (e.g., the transaction’s non‑malleable digest component per ZIP‑244/245) if we want to reduce authoring foot‑guns

  • Witness (prefix‑free):

    • proof (byte string) in the pinned Stone or Stwo wire format, subject to strict size caps.

Determinism and non‑malleability of these encodings are the extension’s responsibility, per ZIP‑222: any malleation of precondition must cause tze_verify to reject; the verifier’s output must be deterministic.

Verification

tze_verify for this (type, mode):

  1. Parses verifier_id; loads the exact pinned parameter set (includes hash choice, FRI/query bounds, etc.).
  2. Initializes the proof transcript and absorbs pub_in exactly as specified.
  3. Parses proof per pinned wire format and runs the Stone or Stwo verifier accordingly.
  4. Returns true iff the proof verifies under the pinned params; otherwise false.

Bounds & pricing (DoS safety and fee model)

  • PROOF_MAX_BYTES (consensus): a conservative constant per mode and possibly per verifier_id. Initial discussion ranges could be 64–256 KiB for Stone and ≤256 KiB-1MB for Stwo (subject to benchmarks on realistic traces).
  • PUBIN_MAX_BYTES (consensus): e.g., ≤ 32MB.
  • Runtime bound: implied by pinned FRI/query limits + hash choice + byte caps; parser must fail fast on malformed inputs and cap allocations.
  • Fee signal: bytes (witness size). This mirrors how Zcash currently prices transaction bytes; we avoid introducing new “op‑count” style budgets unless needed.
  • Policy (non‑consensus): start with strict mempool limits (e.g., at most one STARK_VERIFY input per transaction; tighter size limits under policy). These can relax as we gain operational experience.

Starknet‑style L2 sketch (informative, not part of this TZE spec)

  • Bridge model: L1 TZE outputs carry a precondition that references the current L2 state root; L2 operator(s) post a STARK proof that a batch of L2 transactions moves state from root_old to root_new. The witness contains that proof; the precondition carries the public inputs (roots, batch commitments, etc.).
  • Data availability (DA): out of scope for this TZE. DA can be a) fully on‑chain (expensive), b) via commitment to an external DA layer, or c) hybrid. The precondition must make the DA commitment explicit if required by the verifier.
  • Deposits/withdrawals: are protocols on top of this primitive, potentially combined with ZSAs to represent L2 balances on L1.

References / prior art

Next steps

  • If there’s interest, I’ll draft a ZIP titled “STARK verification as a Transparent Zcash Extension” (Category: Consensus), cross‑referencing ZIP‑222/244/245.
  • The ZIP will include: exact wire formats; pinned parameter sets for Stone and Stwo; consensus bounds; test vectors; and a plan for staged activation.
22 Likes
2

Why not directly make starknet a Zcash L2 as well?

3

you mean the public Starknet to migrate to ZCash instead of Ethereum / Bitcoin ? to extend to also settle on ZCash ?
technically everything could be possible. it’s not only a matter of technical options as you might understand.
but the proposal is agnostic to those non technical challenges anyway.
and Starknet stack is open source so this would enable anyone to build a Starknet based L2 on top of ZCash, not necessarily StarkWare.
But thanks for this suggestion, it’s interesting!

1 Like
4

In other words, if this proposal is implemented it would bring L2 programmability to Zcash, and can become a potential path/bridge for encrypting and shielding token and other assets from ethereum ecosystem :thinking:?

5

yes! you got it right. not only programmability btw, also scaling and UX improvements.

1 Like
6

Hey @abdel - great to see you outside of the bitcoin space :slight_smile:

Super interested in this. I wrote this proposal a year or so ago (there are technical errors in the post fwiw), but conversations at the first Zeboot shifted towards Zcash having its own rollup ecosystem versus rolling up somewhere else.

This might be an interesting GitHub issue to review. It was re-discussed during my presentation at the first Zeboot 18~ months ago. Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub

Let me know if you would like me to review any other documentation/ideas you have on this. I know there’s an appetite for this. Nate (shielded labs) and I discussed this idea recently on a Twitter space with ZecHub.

3 Likes
7

ohhhh good to see you here my friend!!!
oh interesting i missed this!
wow stars are aligning. yeah let’s work together bro. i have many ideas. glad to see there is appetite. let’s consolidate and join forces.

3 Likes
8

Yes, super interesting proposal!

Curious what @daira and @pacu think about the feasibility of getting this into a NU?

(assuming the larger community supported it of course)

4 Likes
9

thanks!
curious too!

10

Hello @abdel! Thanks for posting this idea. I don’t know much about Cairo VM but I know that there’s a vibrant community of builers over there.

I have a few insights:

Given that @ebfull has estimated that Tachyon could be developed within the next 12 months or so, how would that interact with your proposal?

When it comes to finality, does your proposal depend on Crosslink being implemented and deployed or is the PoW consensus enough to go by at first?

Cheers!

1 Like
11

This is very interesting. There is great opportunity to continue to make ZCash everything Bitcoin could have been and embracing L2s is part of that IMO.

I can’t speak to the implementation of ZSAs but am I correct that bridging shielded ZEC to an L2 account would require future work and is outside of the scope of this initial proposal? Without private transfers or programmable privacy on the L2, it seems the main or sole benefit of the L2 would be driving tx fees to the L1 via settlement. However with the L2 space very crowded, I assume people would only be attracted to this option if it had privacy and was an extension of the ZCash ethos. IMO it makes sense that any proposal includes at least a plan for privacy on the L2 from the beginning, even if the implementation and rollout is staged.

1 Like
12

I don’t think it is a good idea to promote transparent L2s as part of “Zcash”. It carries similar problems as the transparent pool.

I do think we should eventually build a L2 for Zcash to add programmability, but it should be based on FHE technology so that we don’t lose privacy.

2 Likes
13

Yeah Starknet definitely has a very vibrant community of builders! And Cairo is a great language to build scalable verifiable apps. The DexX keeps improving at fast pace and there are more and more great example of cool apps working in production at large scale.

Regarding Tachyon I need to check as I am not really familiar with it. I will try to check soon and comeback with insights on how this would interact with this proposal.

PoW consensus enough to go by at first for sure, no problem about this any time soon.

1 Like
14

Starknet does not have privacy support, yet! The proof verification is agnostic to this btw and it would totally be possible to verify ZK proofs that are actually ZK and privacy preserving.
So it’s not an issue regarding this specific proposal.

1 Like
15

There is great opportunity to continue to make ZCash everything Bitcoin could have been and embracing L2s is part of that IMO.

Agreed. And for us it would honestly be an amazing field of experimentation / anticipation on what Starknet on top of Bitcoin could look like in the future.

am I correct that bridging shielded ZEC to an L2 account would require future work and is outside of the scope of this initial proposal?

Correct. Outside of the scope of this initial proposal. But this proposal is a prerequisite to think about this as a later step.

it seems the main or sole benefit of the L2 would be driving tx fees to the L1 via settlement.

Yes the main advantage is scaling, but not only. Also UX and expressivity. With account abstraction you can build amazing UX, especially for normies, while remaining trustless and self custodial.

IMO it makes sense that any proposal includes at least a plan for privacy on the L2 from the beginning, even if the implementation and rollout is staged.

The proof verification on L1 (this proposal) would TOTALLY enable this going forward. To be specific and give a concrete example, once we had proper ZK support in stwo (our next gen prover) and privacy support in the Starknet OS, this would naturally enable privacy on the L2.

2 Likes
16

Update: TZE-based Circle‑STARK verification vs. opcode fallback: constraints, options, and questions

Context. I started a PoC to verify Stwo/Cairo (Circle‑STARK) proofs on Zcash L1 using Transparent Zcash Extensions (TZE). While wiring this into Zebra I also evaluated an opcode fallback. Below is what I learned, plus concrete paths we could take.

What I learned (facts & constraints)

  • TZE exists at the spec level and is designed for large, typed, non‑script witnesses.
    ZIP‑222 defines TZE objects (preconditions/witnesses) and how they integrate with transactions without touching Script; ZIP‑245 defines how TZEs are committed in the txid/sighash/auth digests. This is the cleanest way to carry and verify big proof blobs in consensus.

  • Zcash Script alone can’t carry large ZK proofs.
    Transparent Script inherits Bitcoin‑style resource limits (stack item and script size). Even if we chunked a proof, Script limits and lack of native covenants make feeding ~100 KB+ proofs via Script unrealistic. (Zcash’s non‑malleable txid/sighash split from ZIP‑244 doesn’t create a separate “witness stack” for transparent inputs.)

  • If we avoid TZE, we still need a way to feed big data to consensus.
    The only practical “opcode path” is to introduce a per‑input witness area in the v6 tx format (added to the authorizing‑data digests per ZIP‑246), and have the opcode read from there. Otherwise the opcode has no way to access multi‑10s/100s‑of‑KB inputs.

  • Implementation surfaces today.

    • Zebra is modular and already separates Script from consensus.
    • The Script interpreter lives in zcash_script, which has a pure‑Rust implementation (and a C++ FFI). If we go the opcode route, I’d target the Rust engine to avoid FFI for the Stwo verifier.

Options on the table

A) Stay on the TZE track (my original proposal)

  • What: Define a single TZE type “Circle‑STARK Verify”. Precondition commits to program + public inputs (e.g., L2 root transition or app message). Witness contains the Stwo proof blob. Nodes verify via a Rust adapter.
  • Why: TZE is purpose‑built for this: large, typed witness; crisp digest integration via ZIP‑245; no pressure on Script limits.
  • Work: Finish a minimal TZE host path in Zebra; pin verifier params; add size/runtime caps; test vectors; tooling to construct TZE txs.
  • Pros: Architecturally clean; lowest risk of resource‑limit surprises; forwards‑compatible with other extensions.
  • Cons: TZE infra isn’t widely exercised yet; requires Zebra/RPC/wallet changes to expose/build TZE txs.

B) Opcode fallback — but with a small v6 format addition

  • What:

    1. Add a Transparent Input Witness (TIW) per transparent input in v6 (exact encodings + digest placement under ZIP‑246).
    2. Add OP_STARK_VERIFY that reads (pub_inputs, proof) from the TIW for the current input and runs the pinned Stwo verifier.

  • Why: Looks/feels like “a single opcode”, but avoids Script size/element limits by moving large data to TIW (committed in authorizing‑data digests, excluded from txid per ZIP‑244/246 semantics).

  • Work: Two small consensus ZIPs (TIW layout + opcode semantics), zcash_script opcode + host callback to read TIW, Zebra v6 parsing and digest updates, policy caps.

  • Pros: Narrow change set; no new TZE object model; can be implemented entirely in Rust.

  • Cons: Still a transaction‑format change; wallets/RPC must learn to build/inspect TIW; less general than TZE.

C) Opcode‑only with no format change

  • What: Try to push proof bytes through Script itself.
  • Reality check: Not viable at realistic proof sizes without lifting Script limits and/or introducing covenants (e.g., OP_CAT‑style constructions). That’s a much larger design discussion with more risks.

What I need feedback on

  1. Preference for TZE vs. opcode+TIW.
    From a consensus/maintenance perspective, which path is more acceptable for NUx? My read is that TZE (A) is architecturally right, while opcode+TIW (B) is the smallest alternative that actually works.

  2. Are there near‑term plans to ship TZE?
    ZIP‑222 and ZIP‑245 are Draft. Is there an intended activation window for a first TZE type (not necessarily this one)? If yes, I’ll align with that process.

  3. If we go (B), is a small v6 “TIW” addition acceptable?
    Concretely: per‑input byte‑strings included in the authorizing‑data tree (per ZIP‑246), excluded from txid (per ZIP‑244 principles), with conservative consensus/policy caps. Any gotchas with digest plumbing or signer UX I should account for?

  4. zcash_script engine: Rust path OK for consensus?
    I’d like to target the pure‑Rust interpreter in zcash_script for the opcode. Is that considered feature‑complete and acceptable for Zebra’s consensus path, or should I go through the C++ FFI? (Trying to avoid Rust↔C++ FFI for the Stwo verifier.)

  5. Resource bounds.
    What proof size and CPU budget would reviewers be comfortable with? (E.g., < 192–256 KiB proof bytes; < N ms on standard hardware). I’ll produce benchmarks once we agree on a direction.

  6. Process: where to place the work.

    • If (A): I’ll update the TZE ZIP (Circle‑STARK Verify) and continue a Zebra PR that wires a TZE host path and the Stwo adapter.
    • If (B): I’ll split into two ZIPs — TIW for v6 and OP_STARK_VERIFY — and prepare zcash_script + Zebra PRs accordingly.

  7. Tooling expectations.
    For either path: preferred RPC shape for building/inspecting TZE/TIW; any minimum wallet SDK hooks needed for signers (since the authorizing‑data digest must commit to the proof).

2 Likes
17

Fully supportive of this expedition.

2 Likes
18

It’s an interesting idea that deserves further exploration. I agree that TZEs are probably the best mechanism for this if it goes forward.

5 Likes
19

TZEs do not just exist at the spec level. TZEs were implemented for integration into zcashd:

The zcashd PR was never merged because TZEs are not a standalone feature and can’t be independently “activated” in a network upgrade: they are a framework for deploying new UTXO-style transparent pools to Zcash, and only make sense in the context of at least one such pool being added to the consensus rules. The Rust code OTOH has been living quietly in the librustzcash repo behind feature flags, and we’ve been maintaining it across refactors of the rest of the Rust code.

3 Likes
20

From a chain data perspective:

  • Sapling (Groth16) requires around 400 bytes of proof data per logical action (1 Spend + 1 Output). The minimum ZIP 317 fee covers 2 logical actions, so around 800 bytes of proof data, but in practice wallets only pad the outputs (so the smallest typical Sapling-only tx is 1-Spend 2-Output, with around 600 bytes of proof data).
  • Orchard (Halo 2) has (IIRC, rounding up quite a bit) a base cost of 2.5 kiB and a marginal cost of 2.5 kiB per logical action (1 Action). The minimum ZIP 317 fee covers around 7.5 kiB of proof data.
    • We accepted this one order of magnitude (12.8x on typical, 9.6x on equivalent) increase in proof data size, in exchange for Orchard having no trusted setup.
    • We kept the fee per logical action consistent between Sapling and Orchard because we didn’t want to discourage usage of Orchard, and the 10x proof data size increase was still manageable.
  • Transparent (Bitcoin-derived Script) has a maximum script size of 10,000 bytes. The marginal ZIP 317 fee uses a typical P2PKH input size (150 bytes) and output size (34 bytes) as the cost of 1 logical action (providing approximately equivalent functionality to Sapling and Orchard), so a single max-size Input would count as a bit under 70 logical actions, and a single max-size Output would count as a bit under 300 logical actions (with the fee being based on whether the transparent input or output logical count is larger in the tx, per ZIP 317).
  • From a raw data perspective: ZIP 231 Memo Bundles (currently proposed to be deployed in NU7 as part of the v6 tx format) have a maximum single-memo size of 16 kiB, or at most 17 kiB of ciphertext data. Per the ZIP, this largest-size memo would be counted as 62 logical actions (2 free memo chunks are provided for historic reasons, but essentially it’s 1 logical action per 272 bytes).

Your proposed example upper bound of 192-256 kiB would be a:

  • 12-16x increase over max-size ZIP 231 Memo Bundle data.
  • 20-26x increase over max-size transparent (for either 1-Input or 1-Output being large; half this if both are).
  • 26-34x increase over 2-Action Orchard.
  • 246-328x increase over 2-Spend 2-Output Sapling.
  • 328-437x increase over 1-Spend 2-Output Sapling.

We had previously decided that 1 order of magnitude increase in proof data over Sapling would not harm the network. The Zcash ecosystem would need to think very carefully about the implications of an >2 orders of magnitude increase over Sapling, and (if that upper limit cannot be lowered without compromising the entire feature) how fees would map to it for controlling the cost to the chain, or what the plan would be to reduce the chain cost over time.

  • For example, if calculated using the same marginal cost as memo bundles (which may be too low given that proofs have a verification cost in addition to a size cost), a max-size STARK proof using the example upper bound would be 722-963 logical actions.
4 Likes