An Opinionated Overview of ZK Tooling and Proof Systems Right Now View this post on my blog for the most up-to-date version! When entering the ZK space, it's easy to be overwhelmed. Everyone is shilling their own protocol, and there are a ton of different proving standards and papers coming out every day. Folks often have similar questions on how to think about different ideas and protocols security, efficiency, and tradeoff wise. Unfortunately, its very hard to quickly distinguish what is worth investing into, and all of the precise security guarantees or undisclosed "gotchas". I will summarize how I am personally currently thinking about the space of ZK tech, especially as we make decisions for what to prioritize for our own code and protocols. I am not perfectly versed in all of the tradeoffs of all of the recent ideas, but this will be a live doc updated as I read and learn more, and folks comment corrections. This is NOT an indictment of the ideas/protocols I don't highlight or cover favorably, nor does this represent the opinions of anyone I cite or credit (they are my interpretations only). I am aiming to make an intellectually honest survey, and so if I misunderstand something, please tell me (telegram, twitter) -- I am very open to continual changes and improvements, especially as the space and this tech rapidly evolves. You can leave comments on this hackmd. Thanks to Nalin, John, Yi, Richard, Sora, Ratan, ShuklaAyush, and Vivek for thoughts on this post, in addition to the countless folks behind these protocols themselves, and folks who I've had conversations with regarding zk over the last 2 years! Thanks to Richard and Sachin for touching on many of these points in their ZK Summit London talk as well. Last updated Nov 5, 2023. ZK Proving Languages and Stacks

Why the ZK Hacker house Creating a ZK hacker house during Devconnect and ZuConnect in Istanbul provides a dual advantage of cost efficiency and enhanced collaboration. The aim is to continue the in-person momentum from the Funding The Commons Residency that builders and PSE projects experienced. By housing individuals under one roof, we not only save on accommodation costs but also establish a nexus for intellectual exchange and collaborative efforts around ZK projects. This convergence of diverse talents and minds will expedite innovation, offering a real-world testing ground for projects and amplifying the outreach and impact of ZK projects. Moreover, by establishing an intimate container for trust and rapid prototyping, a hacker house can support the depth needed to innovate ideas and create trust for building critical tools. 0xPARC has proven that residencies create long-term value — we are excited to help PSE harness the creativity from many projects and oss contributors as well. A house for 10-20 people can create a Schelling point at a similar cost to what individual accommodations for each person would have cost, while creating a schelling point for activity at zuconnect. An experiment with a small scale hacker house can help validate in person hacker houses as a tool for PSE to further ZK projects, and creating an operational playbook with Sara and Aayush can be a meaningful start. At least half will already be PSE affiliated/funded, as this will primarily be a zk house. A few talented external oss devs are invited too — we’ll send a blurb out to axioms halo2 learning group and japan’s zk program; it’s important to continue to engage those people in interesting projects. People without ideas yet can source projects from aayushg.com/ideas > crypto and github.com/zkemail > projects, as well as whatever the existing PSE projects want help with. Goals Continue to ship novel public goods-related projects built off of new cryptographic tech like zk email, zk nfc, plumes, etc Create a focused and collaborative working environment for open-source builders, especially those with PSE

💸 Hard Problem Statement Quantum computers will break Ethereum and Bitcoins signing scheme by allowing anyone to reverse engineer a secret key from a public key. Luckily, addresses are safe; if we make public keys "quantum-secret" and don't reveal them either, then there is a path for plausible quantum resistance without many changes to the system. Links to understand: Nontechnical intro: https://hackernoon.com/quantum-contingencies-in-cryptography-a-short-primer-fd143xrp Technical breakdown without solution: https://www.ledger.com/blog/should-crypto-fear-quantum-computing (ignore their "IS THERE A CURE" section -- they didn't consider this solution) Technical breakdown with solution: https://blog.aayushg.com/posts/quantumcryptoIn-Depth Technical Solution + Discussion: https://ethresear.ch/t/quantum-proof-keypairs-with-ecdsa-zk/14901 ECDSA Signature Details (and more efficient version that may or may not be quantum proof), by Dan and Vivek: https://personaelabs.org/posts/efficient-ecdsa-1/ Account Abstraction: https://ethereum.org/en/roadmap/account-abstraction/ Bonus: Pretty Quantum Math Animations for RSA by Veritasium:w https://www.youtube.com/watch?v=-UrdExQW0cs