Check out the latest episode of Node Guardians to see our cofounder David Wong talk about ZK security and the future of ZK with Sam. In this episode, David discusses the different workflows that can be used for blockchain auditing, the importance of math in auditing, and the scope of work that blockchain auditors typically perform. He also talks about the challenges of working in different contexts, how vulnerabilities are rated, and the usefulness of formal verification.
In this final post of the series, we extend univariate KZG commitments to multilinear polynomials through Mercury. Building on Gemini, we fold half of the variables at once, use polynomial division to bind this large fold to the original commitment and reduce the remaining multilinear evaluations to a batched inner product check. We then walk through the end-to-end opening protocol. We conclude by examining its proof size, prover cost and verifier cost.
In this blog post, we extend univariate KZG commitments to multilinear polynomials through Gemini. We introduce recursive partial evaluations, derive the split-and-fold identity and express each fold as a univariate identity that can be checked using KZG openings. We then walk through the end-to-end opening protocol. We conclude by examining its proof size, prover cost, and verifier cost.
Many of us are using AI to generate code. Vibe coding cryptography is especially sensitive - you have to uphold strict mathematical correctness. This can lead to wrong security guarantees and soundness bugs. We will discuss what are some patterns to do it well.
We're excited to share that our programming language, noname, now supports R1CS, making it easier to write zero-knowledge (ZK) circuits and deploy them on Ethereum using SnarkJS. This update introduces an alternative to the common Circom language, with a simple and intuitive syntax inspired by Rust and Golang. In this post, we illustrate how to deploy a noname-based Sudoku circuit on Ethereum, demonstrating core benefits like proving a solution's correctness without revealing it. Dive in to explore how noname could potentially unify the fragmented zkSNARK ecosystem and simplify your circuit writing process!
We're super excited to introduce noname 3.0, our zk programming language inspired by Rust and Golang, now achieving full feature parity with Circom. This update brings native hints, a standard library, debugging features, and a lot more to enhance developer experience. Dive into how hint functions work with an 'unsafe' keyword to balance innovation and security, explore our new stdlib modules, and see how the compiler pipeline visualizer can help you understand the compiling process. Plus, check out our next steps and how you can contribute to shaping noname's future.
We're excited to introduce the preview of noname 2.0, packed with features that make developing advanced ZK circuits easier than ever. This update includes flexible generic-sized arrays, seamless integration with folding schemes for IVC, and an interactive online playground to test and share code. We've also optimized R1CS constraint generation to boost performance. Plus, there are numerous community-driven enhancements and bug fixes that make the language more robust and user-friendly. Dive in to explore the specifics of our journey, learn from the contributions of our vibrant open-source community, and see how noname is evolving into a more versatile tool for developers.
Groth16 is still the gold standard for succinct SNARKs: 128-byte proofs, constant-size verification, and a decade of real-world deployment. But despite its ubiquity, almost nobody explains *why* it works the way it does. In this post, we build Groth16 from the ground up, starting from R1CS and QAPs, then layer in pairings, trusted setup parameters, and the separator tricks (α, β, γ, δ) that make the scheme sound. By the end, you should have an intuitive grasp of every term in the final verifier equation.
In this blog post, we explore an optimization for Barrett reduction, a popular method for modular arithmetic. We discovered that the error bound can be tighter than traditionally thought, meaning you often only need a single subtraction instead of two. This tweak can speed up cryptographic operations like those in the RustCrypto library by 14% when applied to NIST curves, which is a game changer for both encryption and performance. Dive into the details to see how this simple change can lead to significant improvements in real-world applications!
In Session 10 of "Proof is in the Pudding," we work backward from Groth16's famously compact verifier equation to explain why the protocol is shaped the way it is. We cover how R1CS constraints become polynomial identities, why pairings are needed to multiply hidden commitments, how random linear combinations and the Schwartz-Zippel lemma enforce witness consistency, and how the separating factors gamma and delta restrict which pieces of the CRS a prover can use.