In this post, we will examine one of the most interesting ways to construct zero-knowledge proofs: the MPC-in-the-Head transformation. This was first introduced in the 2007 paper Zero-knowledge from secure multiparty computation, and it is often referred to as the IKOS transformation, from the initials of the authors of the paper. The transformation allows us to construct a zero-knowledge proof system from any MPC protocol, which is treated as a black-box.

In November 2024, we discovered an inflation bug in the Aleo mainnet. We immediately reported this bug to the Aleo team. The bug was identified and then quickly fixed. Fortunately, no exploitation was detected after a thorough scan. Thanks to the Aleo team for their prompt and professional action. In this article, I will explain the context of the bug, how it could have been exploited, and how it was fixed.

In 2024, we released a paper on the security of Blockchain Rollups in collaboration with Matter Labs. The paper analyzes the security of blockchain rollups and introduces a formal model to reason about different mechanisms. You can find the paper on arxiv. In this blog post, we will discuss the security of Rollups and provide a gentle introduction to what we did in our paper. In his recent blog post, Vitalik Buterin highlighted that while Ethereum aims to be a robust, multi-purpose blockchain, there is only so much it can handle on its own.

We are excited to announce the launch of bugs.zksecurity.xyz, a website dedicated to documenting and analyzing past vulnerabilities in ZK circuits. This website serves as an open repository where developers, researchers, and security professionals can explore past security issues, reproduce known vulnerabilities, and contribute to improve this knowledgebase. On the website and the zkbugs repo, you will find: A Catalog of ZK Bugs: A growing dataset of known vulnerabilities in ZK circuits, each documented with descriptions, root causes, and potential mitigations.

A few years ago, mathematician Kevin Buzzard had a troubling realization: mathematics relies on trust — trust that proofs are correct, trust that reviewers will catch mistakes, trust that errors don’t go unnoticed. But what if that trust fails? Throughout his career, Buzzard had to argue with numerous researchers who refused to admit their proofs were wrong, despite clear flaws! Eventually, this made him lose trust in “human-checked” mathematics. Luckily for mathematicians like Buzzard, interactive theorem provers — also known as proof assistants — are on the rise.

In our previous post, we delved into the Jolt zkVM and uncovered several significant bugs in the code. In this post, we will provide a detailed walkthrough on how Jolt actually works. Jolt is a zero-knowledge Virtual Machine (zkVM) designed for the RISC-V architecture and developed by a16z. It employs the Lasso lookup argument to prove the correctness of VM execution. While often praised as the simplest zkVM, Jolt is a relatively new protocol with limited resources explaining its functionality.

A zkVM (Zero-Knowledge Virtual Machine) uses zero-knowledge proofs to prove and verify computations run in specific ISA (Instruction Set Architecture). Existing zkVMs (e.g., risc0, sp1, jolt, valida, zkm) allow developers to write programs in high-level languages like Rust or C++ without needing to worry about the complexities of ZKPs. It abstracts away the underlying cryptographic details, enabling developers to focus on their application logic and ship faster. Once a zkVM is secure, it provides “out-of-the-box” ZKP functionality to any program running on it, giving developers the benefit of zero-knowledge proofs without additional effort.

Over the past few weeks, zkSecurity took a deep dive into a16z’s Jolt zkVM. This joint effort with a16z aimed to help strengthen the security of their zero-knowledge (ZK) stack. Jolt’s zkVM is positioned to become a key player in the zk space, and security work like this is essential to ensuring it can deliver on its promises. Through this review, we uncovered several significant bugs. These issues could allow a malicious prover to forge proofs with ease, posing serious risks.

In our partnership with Starknet, we have performed a number of security audits on some of the network’s cryptographic components. One challenge we encountered was the lack of comprehensive specifications – a common hurdle in the ZKP space. To navigate this, we had to reverse-engineer the protocol, piecing together its logic from various sources and observations. In this quest to understand the true protocol being implemented, we wrote and published draft specifications for a number of the protocols that we looked at.

In collaboration with the Zircuit development team, we are excited to announce the release of a course on Halo2 development. Unlike the excellent Halo2 book which focuses on the proof system itself, this course focuses on teaching Rust developers how to develop Halo2 circuits from scratch – without any prior knowledge of Halo2, PlonK or developing circuits for zkSNARKs required. You don’t need to be a cryptographer to follow along!