Abdel proposes "adding an opcode, OP_STARK_VERIFY, to Tapscript that verifies a bounded-size STARK proof. The goal is to enable on-chain verification of a Zero Knowledge Proof with transparent, post-quantum-secure assumptions, without resorting to ad-hoc Script encodings (e.g., OP_CAT) or enshrining a large family of arithmetic opcodes."
It's certainly not even near the draft BIP, so it seems like more of an information gathering exercise.
There is increasing interest in enabling zero-knowledge proof verification within Bitcoin to support applications such as Validity rollups, post-quantum signatures, and privacy-preserving transactions. Current approaches, like BitVM-style optimistic fraud proofs with ZK verification, rely on off-chain computation and on-chain challenge mechanisms, introducing complexities such as delayed finality, capital lockup, and additional trust assumptions.
The actual mechanism Abdel proposes to make this happen
would add a single opcode that consumes a serialized and compressed STARK proof, from the stack, succeeding if the proof verifies and failing otherwise. Proof sizes are typically in the range of hundreds of KB to 1 MB uncompressed, but compression (e.g., bzip2) could reduce them below 100 KB in many cases. On-chain verification time would be in the order of 10s of milliseconds on standard hardware, depending on proof parameters.
100kB is still a pretty big transaction. But it might be worth it if you can do something very useful. Abdel lists a few different use cases:
- Validity rollups for scaling Bitcoin L1: verify state transition given the onchain state commitments.
- Post-quantum signature aggregation: replace a large number of PQ signatures with a single succinct proof of their correctness.
- Privacy features like shielded transactions: spend UTXOs by providing a ZK proof of funds. And some other stuff:
- Proof or reserves / liabilities schemes for Cashu: use STARK proofs to prove the Mint is acting correctly, or users prove that the Mint is cheating. Avoid fractional reserves by having a large portion on Bitcoin onchain, and use it to penalize the Mint if cheating.
- Account abstraction: enable various ways of authentication on the L2 (i.e Oauth, Face ID, Nostr, etc)
- P2P exchange between BTC and fiat by providing proofs of transfer via Wise, Revolut, Venmo, etc, using ZK-TLS.
While I'll admit I don't have a very good grasp of Starks and how they work, I can imagine a few ways this might not be such a good idea. My understanding is that there are a number of ways to do Starks and it seems that committing to one particular method by making it an op code might result in some unintended consequences.
Abdel lists a few other risks and drawbacks:
- Enshrining a proof system: Pins one verification algorithm/format into consensus. Mitigations: small verifier_id namespace to allow additional pinned sets if ever needed.
- Complexity & audit surface: A verifier is non-trivial C++ code; we need a crisp, specification-first definition plus a minimal, auditable implementation bound to a precise commit and compiler settings. Stone is already formally verified, which helps. It also has been used in production for many years at scale and has been audited by multiple parties.
- DoS and worst-case behavior: Must bound proof parameters and sizes conservatively; policy can be stricter.
- Credible neutrality: Avoid favoring one particular protocol. This seems to be the biggest challenge with the approach of enshrining directly ZK verification to Bitcoin. It’s probably best to stick to a well understood, generic, documented vanilla STARK protocol (extremely close to the original STARK paper) and parameter set, not any app-specific semantics.
OP_CAT, thenCTV/CSFS, now a bespoke opcode.