Last February, we published a paper on systemizing vulnerabilities in Zero-Knowledge Proof (ZKP) implementations with collaborators from TUM, Imperial College London, Scroll, EF, and MatterLabs. Building on the dataset we released alongside the paper, we have been working to create a comprehensive GitHub repository where we reproduce known ZK circuit vulnerabilities. Reproducing these vulnerabilities serves several important purposes: Understanding Attack Vectors: Replicating vulnerabilities allows researchers and developers to gain deep insights into how specific attacks are executed.

We are thrilled to unveil the upcoming release of noname 2.0 preview; a major leap forward in the noname language! This release will introduce powerful enhancements that enable developers to write more sophisticated ZK circuits. The notable enhancements include: Generic-Sized Arrays: Unlock greater flexibility and effectiveness in your circuit code by enabling functions to handle arrays of varying sizes. Folding Schemes via Sonobe Integration: Seamlessly create your circuits for IVC (incremental verifiable computation).

Aleo is a blockchain platform that utilizes zero-knowledge cryptography to enable private and scalable decentralized applications. Central to Aleo is Leo, a high-level programming language tailored for developing private applications. Leo allows developers to focus on creating applications with strong privacy without needing to consider the intricacies of zero-knowledge proofs. Understanding and utilizing the unique features of Leo is essential for developers aiming to build robust and secure solutions. This article provides a brief introduction to Leo, with a focus on its security features and practical tips for developers.

We have been working with StarkWare on building the EVM adapter, and are pleased to announce that we have recently successfully verified Cairo proofs on the Ethereum mainnet! We are furthering the work of Andrew Milson and Aditya Bisht who have reached this milestone before us, and we believe that this is a big step forward towards making StarkWare’s technology more accessible to the open-source community. In this post, we’d like to share some background into how Cairo programs are verified on Ethereum, and perhaps motivate some of our readers to try out our code.

We just released a paper on the security of Byzantine Fault Tolerant (BFT) consensus protocols in collaboration with Matter Labs and Sigma Zero. The paper is a collection of lessons learned from analyzing the real-world security of various BFT consensus protocol implementations. You can find the paper on eprint. Here is the abstract: This paper presents a collection of lessons learned from analyzing the real-world security of various Byzantine Fault Tolerant (BFT) consensus protocol implementations.

On February 26, 2024, Renegade tasked zkSecurity with auditing parts of its circuits and smart contracts. The specific code to review was shared via GitHub as public repositories. The audit lasted 3 weeks with 2 consultants. You can find the full report here. We found the implementation, as well as the surrounding documentation and specifications, to be of the highest quality. The Renegade team was very responsive and helpful in answering questions and providing additional context.

Introduction Recently Ethereum deployed EIP-4844 (Proto-Danksharding) to lower the cost of “data-availability” on Ethereum. The high-level goal of data-availability is, well, to ensure that a piece of data is available to everyone who wants it. Data-availability is primarily a concern in relation to roll-ups, where the problem it solves is the following: even if a roll-up proves honest execution using a SNARK, what happens if the roll-up operator stops telling people which transactions they are executing?

We’re excited to announce our participation in Bain Capital Crypto’s Whiteboards series! In the inaugural episode, David teams up with Guillermo Angeris, Bain Capital Crypto’s Head of Research, to delve into the fascinating world of Multi-Party Computation (MPC). Watch the full episode and explore the cutting-edge of multi-party computations. part 1: additively-shared secrets in arithmetic circuits. part 2: Shamir Secret Sharing and multiplications. Need auditors to look at your MPC stack?

Introduction In zero-knowledge proof systems, we (almost) always operate over a finite field and because the prover usually has to do a lot of field operations to generate the proof, we naturally want our field operations to be as fast as possible. With elliptic curve cryptography we are restricted to fields of “cryptographic size” e.g. around 256 bits for 128 bits of security. However, STARK-like techniques (Reed-Solomon IOPs) have no such direct dependency between the security parameter and field-size.

Zero-knowledge proofs (ZKPs) have evolved from being a theoretical concept providing privacy and verifiability to having practical, real-world implementations. Some of the most common use-cases are for private transactions in blockchains (e.g., Zcash), blockchains with private smart contract capabilities (e.g., Aleo, scalability through off-chain validity proofs (e.g., zk-rollups), infrastructure for secure non-custodial authentication (e.g., zkLogin), and private-focused applications such as ZKEmail. All of those examples are build on top of SNARKs.