[DRAFT ZIP] Circle STARK Verification as a Transparent Zcash Extension #1107
Conversation
zips/draft-stark-verify-nu.md
Outdated
|
|
||
| # Terminology | ||
|
|
||
| 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). |
There was a problem hiding this comment.
| 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.)
Fix stark verify tze proposal according to the guide
|
your comments have been addressed @daira , thanks a lot for the comments and feedback |
| @@ -0,0 +1,150 @@ | |||
| ZIP: XXX | |||
| Title: Circle STARK Verification as a Transparent Zcash Extension | |||
| Owners: Abdel <[email protected]>, Michael Zaikin <[email protected]> | |||
There was a problem hiding this comment.
| Owners: Abdel <[email protected]>, Michael Zaikin <[email protected]> | |
| Owners: Abdel <[email protected]> | |
| Michael Zaikin <[email protected]> |
|
|
||
| ## Abstract | ||
|
|
||
| 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. It specifies: |
There was a problem hiding this comment.
"L1" and "L2" are not defined (and I don't want readers to rely on intuition from other chains because I think it will be useful to define them using other Zcash terminology).
| - `param_id = 0x0001` — `STWO_V1_P1` | ||
|
|
||
| - Upstream: `starkware-libs/stwo` at tag TBD, commit `TBD`. | ||
| - Wire format: Stwo proof object at v1.0.0 (exact byte layout pinned in this ZIP's test‑vector directory). |
There was a problem hiding this comment.
We don't normally rely on test vectors as part of a specification. Rather, test vectors are supposed to be a redundant check that can be compared against both the specification and an implementation. (Ditto for the four lines below.)
| - FRI/query caps: exact maximums pinned by vector files. | ||
| - Grinding/nonce: if present in the format, upper bounds are pinned by vector files. | ||
|
|
||
| > Normative reference material for `STWO_V1_P1` (field encodings, wire format, hash personalization, FRI expansions, max queries) is included alongside this ZIP in `zip-XXXX/params/STWO_V1_P1.json` and the accompanying test vectors. Implementations MUST treat those files as normative parts of this ZIP. |
There was a problem hiding this comment.
This isn't a correct use of MUST. Modulo the comment I made above, it would be:
| > Normative reference material for `STWO_V1_P1` (field encodings, wire format, hash personalization, FRI expansions, max queries) is included alongside this ZIP in `zip-XXXX/params/STWO_V1_P1.json` and the accompanying test vectors. Implementations MUST treat those files as normative parts of this ZIP. | |
| > Normative reference material for `STWO_V1_P1` (field encodings, wire format, hash personalization, FRI expansions, max queries) is included alongside this ZIP in `zip-XXXX/params/STWO_V1_P1.json` and the accompanying test vectors. These files are to be treated as normative parts of this specification. |
| - `PUBIN_MAX_BYTES = TBD` (discussion range: ≤ 4096). | ||
| - `PROOF_MAX_BYTES = TBD` (discussion range: 64–192 KiB; finalize from measurements on realistic proof instances). | ||
|
|
||
| Nodes MUST reject if any bound is exceeded. Bounds MUST be enforced before allocation to prevent DoS. |
There was a problem hiding this comment.
| Nodes MUST reject if any bound is exceeded. Bounds MUST be enforced before allocation to prevent DoS. | |
| Nodes MUST reject if any bound is exceeded, and MUST NOT allow denial of service via memory exhaustion due to allocating memory before bounds are checked. |
The original second sentence would be a slight overspecification.
|
|
||
| ## References | ||
|
|
||
| - [ZIP‑222: Transparent Zcash Extensions (TZE)](https://zips.z.cash/zip-0222) |
There was a problem hiding this comment.
Nit: this is the wrong format for Markdown references.
|
|
||
| ### Fee model | ||
|
|
||
| Fees follow standard byte‑based rules. This ZIP does not introduce an additional "op‑count" or sigop‑like budget. Implementations SHOULD enforce conservative policy limits initially (e.g., at most one `STARK_VERIFY` TZE input per transaction; local size caps stricter than consensus). |
There was a problem hiding this comment.
This is insufficiently specified; it's fine for now but please write a TODO.
3 participants
About
This ZIP defines a new Transparent Zcash Extension that verifies a bounded‑size Circle STARK proof (Stwo). The extension has a single
typeand 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_idallows a minimal consensus change with tight bounds.Discussion in the ZCash forum