Why We Abandoned zkSTARKS
14. Research & Cryptographic Notes
Why We Abandoned zkSTARKs
Performance • Verifier Cost • Browser Limitations
SnarkSide began as a zkSTARK-native prototype. STARKs—offering transparency, no trusted setup, and theoretical quantum resistance—appeared to be a natural match for a privacy-first, constraint-based DeFi protocol. However, the realities of production deployment across EVM ecosystems, user hardware, and on-chain costs forced a hard pivot.
This document explains the engineering rationale for transitioning to a Groth16 SNARK system. The decision wasn’t made lightly—it reflects over a year of benchmarking, DSL migration attempts, and performance profiling across proving stacks.
1. Performance in Browser Contexts
SnarkSide is built for encrypted trading without trusted intermediaries. Users generate ZK proofs of intent, settlement, or vault transitions in-browser—locally, without revealing identity or control.
This imposes hard constraints on the proving environment:
Low memory footprint
WASM-compatibility
Near-instant proving (<2s target)
Support for mobile and low-power devices
Why zkSTARKs Failed:
Cairo-based STARK provers compiled to WASM were often >100MB per circuit.
Proving time on standard laptops for even modest circuits (e.g., intent generation with Poseidon hashing) was 8–12s.
Mobile devices either crashed or locked up.
Browser RAM usage for a single vault circuit frequently exceeded 2GB, leading to UI freezing.
Despite significant effort using STARKy and custom prover backends, zkSTARKs simply couldn't meet the constraints of self-custodial UX. We would’ve had to offload proof generation, which violates SnarkSide’s trust-minimization goals.
2. Verifier Gas Cost in EVM Context
SnarkSide requires on-chain ZK verification for every:
Batched trade match
Vault update
Liquidation proof
LP claim
Each of these must be validated via a SNARK verifier smart contract on Ethereum or rollup-compatible L2s. For this, proof size and gas cost are critical.
Proof size
~128 bytes
20–100+ KB
Verifier gas
~210k
3–5 million
Calldata
Fixed
Variable, bloated
Circuit
Stable R1CS
AIR trace, large
STARK verifiers (especially Cairo) require custom contracts with dynamic execution traces. Most EVM L2s do not support STARK verification natively, making verifier deployment:
More expensive
Harder to audit
Incompatible with gas compression strategies
The result? zkSTARKs made SnarkSide’s encrypted batch verification economically infeasible under current gas limits.
3. Tooling Maturity and Circuit Ecosystem
Groth16 and Circom offer:
Native Poseidon, MiMC, and SHA primitives
Solidity verifier generation (
snarkjs generateverifier)Mature proving pipelines (
circom,snarkjs,zkey)Auditor familiarity
Proven security assumptions (R1CS constraint algebra)
By contrast, STARK environments required us to:
Implement or port all constraints (no Poseidon/MiMC standard support)
Simulate Merkle inclusion manually in STARK DSLs
Write custom witness generators
Deploy non-standard verifiers
Rely on experimental DSLs with poor composability
As of early 2025, STARK DSLs are not production-ready for private DeFi workloads that require:
Tree-based state transitions
Fixed-field arithmetic
Compression-friendly constraints
This lack of developer tooling amplified circuit maintenance cost and risk.
4. Tradeoffs: Trusted Setup vs Transparency
A common objection to Groth16 is the trusted setup. SnarkSide mitigated this by:
Running reproducible ceremonies
Using market-specific CRS per circuit
Destroying toxic waste keys after setup
Planning Plonk/Halo2 upgrades once recursion is required
In contrast, zkSTARKs avoid trusted setup—but we observed:
Heavier witness complexity
Poorer UX
Excessive calldata and RAM usage
The tradeoff favored Groth16, where auditor-readiness and runtime stability outweighed idealistic transparency.
5. What We Still Use STARKs For
Though SnarkSide’s production protocol runs Groth16, zkSTARKs are still used in:
Internal recursive proof benchmarking
Prover compression analysis (for future L2 integration)
Off-chain intent aggregation test harnesses
Academic modeling (via Winterfell)
We track STARK-friendly rollups and plan support for:
Verifier bridges to STARK-native L2s
Recursive proof batching (via Halo2/Plonky2)
Future ZKVM integrations
When zkSTARKs become fast enough for browser proofing and cheap enough for L2 verifier gas, we’ll reintroduce them at the rollup sequencer layer, not the vault or trade execution layer.
Conclusion
SnarkSide doesn’t reject zkSTARKs ideologically. We rejected them because they didn’t meet real-world constraints—yet.
They’re elegant on paper, but costly in production. Fast on high-end hardware, but broken in the browser. Verifiable in theory, but inefficient on Ethereum.
So we chose Groth16.
Because encrypted perps must be usable by anyone, not just researchers.
Because trustless verification must be cheap, not academic.
Because trading privacy demands working cryptography, not wishlist cryptography.
SnarkSide will evolve as proving systems evolve. But until then, we prioritize proofs that execute, circuits that compress, and systems that hold—under real-world load.
Last updated