[DRAFT ZIP] Circle STARK Verification as a Transparent Zcash Extension

[AbdelStark]

About

This ZIP defines a new Transparent Zcash Extension that verifies a bounded‑size Circle STARK proof (Stwo). The extension has a single type and a single mode, and exposes a compact precondition/witness interface suitable for verifying L2 validity proofs on Zcash L1.

Motivation

Zcash already provides strong base‑layer privacy. What it lacks is general‑purpose programmability and cheap throughput. A Starknet‑style L2 executes programs in Cairo (a ZK friendly VM and language), and posts succinct STARK proofs to L1. Verifying those proofs natively on Zcash via TZE keeps L1 privacy unchanged and gives Zcash a clean path to programmable scaling. ZIP‑222 (TZE) is the intended surface for this kind of extensibility without touching shielded protocols or Script.

Stwo provides a modern, high‑performance implementation of Circle STARKs in Rust. Pinning a specific Stwo parameter set behind a small param_id allows a minimal consensus change with tight bounds.

Discussion in the ZCash forum

[daira]

Suggested change

	ZIP: XXX
	Title: Circle STARK Verification as a Transparent Zcash Extension
	Owners: Abdel <[email protected]>
	Status: Draft
	Category: Consensus
	Created: 2025-10-14
	License: MIT
	Discussions-To: <https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486>
	ZIP: XXX
	Title: Circle STARK Verification as a Transparent Zcash Extension
	Owners: Abdel <[email protected]>
	Status: Draft
	Category: Consensus
	Created: 2025-10-14
	License: MIT
	Discussions-To: <https://forum.zcashcommunity.com/t/stark-verification-as-a-transparent-zcash-extension-tze-i-e-enabler-for-a-starknet-style-l2-on-zcash/52486>

[daira]

Suggested change

	The key words **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT**, and **MAY** are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174).
	The key words "MUST", "SHOULD", and "MAY" are to be interpreted as described in BCP 14 [^BCP14] when, and only when, they appear in all capitals.

The convention is for this boilerplate to only mention keywords the document actually uses. Also remove the boldface formatting from keyword uses. (Boldface is used for them in the protocol spec but not in ZIPs.)

[daira]

TZEs are definitely not supported in tx v5, and are not proposed for NU7 which defines tx v6. The version does define TZEs will either use ZIP 245 to define digests, or ZIP 245 will be updated to point to whatever document does define them.

Suggested change

	- digest integration consistent with ZIP‑244/245 (v5) and ZIP‑246 (v6).
	- digest integration consistent with a future transaction version that supports TZEs [^zip-0245].

[daira]

The argument about privacy probably belongs in a Privacy Implications section.

[daira]

Point 1 has specification in the Requirements section. Point 7 is valid but it shouldn't use the capitalized MUST. The fact that this section places requirements on the specification is implicit and needn't be stated. Also, requirements should be kept high-level.

Pinning an Stwo release/commit is not consistent with defining the semantics by specification rather than implementation — what if that commit has bugs? It is fine for this document to link to a reference implementation at a particular commit for each param_id, and a Zcash full node implementation may choose to actually implement it by using that commit (assuming no bugs have yet been found), but that can't be relied on to pin the specification of behaviour.

Suggested change

	The Specification **MUST** ensure:
	1. A **single** TZE `type` (numeric ID assigned by Editors) is defined for **Stwo/Circle STARK verification**. Transactions using this type **MUST** set `tze_mode = 0`.
	2. A deterministic `tze_verify(mode, precondition, witness, context)` with **no implementation‑defined behavior**.
	3. Fully specified, **prefix‑free** encodings of `precondition` and `witness` for this `(type,mode)`.
	4. A `param_id` namespace that **pins**: Stwo release/commit, the proof object wire format, field encodings, transcript/Merkle hash suite and personalization, FRI expansion and query caps, any grinding bounds, and any batch‑verification settings.
	5. Strict consensus bounds (`PUBIN_MAX_BYTES`, `PROOF_MAX_BYTES`, and parameter caps).
	6. Digest integration that follows ZIP‑244/245 (v5) or ZIP‑246 (v6), such that the **precondition** contributes to effecting digests (txid) and the **witness** does not.
	7. Reference test vectors (valid and invalid) and a minimal reference verifier wrapper **MUST** be provided before activation.
	* Define a TZE `type` for **Stwo/Circle STARK verification**, and fully specify how this type is to be encoded, verified, and integrated into transaction digest computation, without allowing implementation‑defined behavior.
	* Define a `param_id` namespace that pins the specification of the Stwo proof relation, the proof object wire format, field encodings, transcript/Merkle hash suite and personalization, FRI expansion and query caps, any grinding bounds, and any batch‑verification settings.
	* A reference implementation of the prover and verifier, and reference test vectors (valid and invalid) must be provided for each such `param_id`.
	* Limits on proof sizes, etc. must be chosen to avoid potential denial of service, and the necessary updates to ZIP 317 fee calculation [^zip-0317] must be specified.