Fog of war games. Currency mixers. ZK-rollups. Dark pools.People are realizing how powerful zero knowledge proofs are - and you too can use this power!I'll teach you everything you need to know about zkApp tooling so you too can harness this power for yourself.👇

1/ But first, why are Zero Knowledge Proofs (ZKPs) so powerful?

ZKPs are private by default, forcing developers to much more intentional about what user data they expose.

If you're still skeptical about ZKPs - check out this thread by @varunshenoy_! It'll change your mind.

@mentions

2/ As an example, and used ZKPs to shuffle a card on-chain without any trusted parties. ZKPs allowed players to submit proof they had shuffled correctly without revealing anything about the shuffle's result!

3/ Using these circuits to shuffle cards, it becomes possible to deploy an anonymous and decentralized version of any card game on-chain. This means truly anonymous poker, blackjack, etc, are possible to build!... I'm not saying anyone should do that. Please don't go to jail.

@mentions4/ So you've been convinced of the power of ZKPs and want to start building ASAP. But you might feel like a zero knowledge goof - where do you even get started?????Like any project, you'll need to start by choosing a tech stack for your zkApp.

@mentions5/ Outside of web3 stack choices (web framework, backend(?), underlying chain), you'll need:- a frontend domain specific language (DSL) or library- a backend proof system.These are constrained by where your prover and verifier are going to be deployed. Let's dig deeper!

@mentions

6/ At its most abstract, the goal of the frontend of a ZKP system is to allow developers to express knowledge about some private or public input.

@mentions7/ Developers use a higher-level DSL like 's Circom, , , or , or a library like or to encode these constraints. 's halo2 or 's plonky2 have you write arithmetic gates directly!

@mentions

8/ Like normal programming languages, these solutions tradeoff between lower-level control and abstraction. (See:

)

@mentions9/ halo2 and plonky2 don't even have frontend DSLs, so they have devs defining arithmetic gates directly.On the other end of the spectrum, Noir aims to resemble Rust as much as possible, abstracting away as much cryptography as possible.Circom is somewhere in the middle.

@mentions10/ Once devs have defined the constraints which make up a circuit in the language, they can "compile" the circuit. The exact process depends on your language and proof system, but you end up with two distinct but important bits of code: a prover and a verifier.

@mentions

11/ This is where the second tech stack choice - your backend proof system - matters. Here, the cryptographers come out to play.

(I suggest:

&

if you want to explore more.)

**[MIT IAP 2023] Modern Zero Knowledge Cryptography**The stream link is here for all lectures. Please reach out to zk-iap-2023@0xparc.org with any questions!https://zkiap.com

@mentions

12/ If you're interested in diving deeper into this process (but maybe not all the way to field theory) at all, I recommend another of 's threads on this exact topic!

@mentions

13/ But for this thread, we can black-box proof systems. All you need to understand is that they make tradeoffs between the following:

- Proof size
- Proof generation speed/cost
- Verification speed
- Setup (i.e. trusted setup, ex:

)

- Expressiveness

**KZG Summoning Ceremony**Add your randomness to the KZG Summoning Ceremony to help scale Ethereum!https://ceremony.ethereum.org

@mentions14/ In practice, your proof generation speed doesn't matter as much, so the most important factor is the cost to verify proofs on your target chain.This is because of the gas costs and size limits of contracts. Sometimes generated verifier contracts are too big to even deploy!

@mentions15/ In cases where you're verifying off-chain, you should first select for tooling based on support for generating provers and verifiers in your desired target environment (i.e. browser/Node backend, Rust microservice, Go game client, etc), and then based on personal preference!

@mentions

16/ Once you have prover and verifier, you can call them from other code.

For example, you could build an anonymous voting app by calling the prover in the browser to generate a membership proof and verifying it in a node backend, like

!

@mentions

17/ Or, you can generate provers in Rust and verifiers in solidity, and call the provers in a optimized game client and the verifiers in on-chain game contracts like 's

client and

's contracts.

The possibilities are endless...

@mentions18/ ...but as mentioned before, the limits of environments like the browser (performance) or the EVM (gas costs and fixed max contract size), as well as the presence or lack of tooling support, complicate this ideal.

@mentions

19/ Also, sometimes language and proof systems combos are exclusive to specific chains.

Languages like and

are designed for

and

respectively, allowing for performance improvements via vertical integration.

@mentions20/ Additionally, a language's compiler pretty much always only supports one proof system!For instance, Noir's compiler barretenberg currently only supports Plonk. Circom is the rare exception, supporting Groth16, Plonk and experimentally, FFlonk.

@mentions

21/ This means you have less freedom to choose your tech than you'd like.

Maybe you want to use Plonky2 because of its recursion and performance characteristics, but you want to use a DSL because you don't want to directly write gates. Unfortunately, that tooling doesn't exist.

@mentions

22/ Other times, maybe you're completely satisfied with the frontend lang and proof system, but there is no implementation of a prover/verifier generator for your target environment.

You can imagine many such cases of missing tooling for every step of the dev process!

@mentions23/ To sum up, while ZKPs are powerful, there's a lot of problems with developing them.- Desirable environments (like the EVM) are hard to target- Needing a specific environment/proof system with specific performance characteristics severely limits your choice of tooling

@mentions

24/ But don't worry - these problems are well known and smart people are hacking on them!

Let's briefly talk about a few directions tackling these problems.

@mentions

25/ One interesting direction is optimizing EVM verifier codegen. For example, wrote a Groth16 verifier generator. Nothing is stopping people from writing codegen to produce verifiers in Huff for other proof systems as well.

**GitHub - whitenois3/huff-snark-verifier: Generate an optimized Groth16 SNARK verification smart contract for use on EVM-based blockchains.**Generate an optimized Groth16 SNARK verification smart contract for use on EVM-based blockchains. - GitHub - whitenois3/huff-snark-verifier: Generate an optimized Groth16 SNARK verification smart c...https://github.com/whitenois3/huff-snark-verifier

@mentions

26/ Generated Huff verifiers are smaller than Solidity verifiers, and are 10-20% more gas efficient on each verify.

This means generating verifiers in Huff allows you to deploy more complex circuits with more constraints.

Also, the verification gas savings add up over time.

@mentions

27/ Another important direction is improving tooling for devs. For example, and other devs at Project Sophon have put out a plugin for Circom, and has put out a similar plugin for Noir.

**GitHub - projectsophon/hardhat-circom: Hardhat plugin to integrate Circom and SnarkJS into your build process.**Hardhat plugin to integrate Circom and SnarkJS into your build process. - GitHub - projectsophon/hardhat-circom: Hardhat plugin to integrate Circom and SnarkJS into your build process.https://github.com/projectsophon/hardhat-circom

**GitHub - spalladino/hardhat-noir: An unofficial Hardhat plugin for working with circuits written in Noir**An unofficial Hardhat plugin for working with circuits written in Noir - GitHub - spalladino/hardhat-noir: An unofficial Hardhat plugin for working with circuits written in Noirhttps://github.com/spalladino/hardhat-noir

@mentions

28/ Aside from build tooling, teams are even improving framework and library tooling! For example, aims to build a higher-level on-chain game engine on simil:ar to what 's

does for the EVM.

**GitHub - dojoengine/dojo: An Onchain Game Engine implemented in Cairo 1.0**An Onchain Game Engine implemented in Cairo 1.0. Contribute to dojoengine/dojo development by creating an account on GitHub.https://github.com/dojoengine/dojo

@mentions29/ Right now, the state of ZKP tooling is akin to web3 development 1 or 2 years ago, before projects like and .But even compared to 6 months ago, the developer experience has improved so much, and will continue to improve, lowering the barrier of entry!

@mentions30/ The last direction I want to tease is work being done in decoupling frontend DSLs and backend proof systems in ZKP compilers.This is a technical and nuanced topic which I hope to save for a future thread, but here's a project to give you a taste of what's to come.

@mentions

31/ The project is Nova Scotia by , which targets Circom to 's recursive proof system Nova.

Clearly frontend DSLs and backend proving systems need not be subject to developer lock-in the way they are now.

@mentions32/ ZKPs are clearly powerful, but there's also still a lot of work to be done building out the tooling to enable developers to easily build and deploy them.Hopefully, I've helped point you in the right direction so you can get started building ZKPs or even help build tooling!

@mentions

33/ Some interesting resources for learning more:

's

's

and

's

's

**Introducing Noir | Noir Documentation**Learn about the public alpha release of Noir, a domain specific language heavily influenced by Rust that compiles to an intermediate language which can be compiled to an arithmetic circuit or a rank-1…https://noir-lang.org

**A beginner's intro to coding zero-knowledge proofs**An introduction to coding and using zero-knowledge proofs, using Circom, Halo2, and Noir.https://dev.to/spalladino/a-beginners-intro-to-coding-zero-knowledge-proofs-c56

**0xPARC PLONKathon**The 0xPARC PLONKathon was a two day learning hackathon, held on January 28th, 2023 and January 29th, 2023. It occurred during the 3rd week of MIT’s IAP period, where we were concurrently teaching the …https://plonkathon.com

**GitHub - matter-labs/awesome-zero-knowledge-proofs: A curated list of awesome things related to learning Zero-Knowledge Proofs (ZKP).**A curated list of awesome things related to learning Zero-Knowledge Proofs (ZKP). - GitHub - matter-labs/awesome-zero-knowledge-proofs: A curated list of awesome things related to learning Zero-Kno...https://github.com/matter-labs/awesome-zero-knowledge-proofs

@mentions

34/ Want to chat about or hack on zkApp tooling? My DMs are open!

Or follow me here or at

- I'm currently hacking on libraries for Circom and Typescript with

which helps address tooling problems for JS and TS devs.

**sigmachirality - Overview**Aspiring Ambidextrous. sigmachirality has 72 repositories available. Follow their code on GitHub.https://github.com/sigmachirality

@mentions35/ Thanks to everyone who took a look at drafts of this thread., , , ,, , and .Y'all are the reason this thread has more grace than a dilapidated walrus.

@mentions36/ Down to read more research at the frontier from researchers?Check out more content from us here: twitter.com/i/lists/162053…