Overview of zkSync Boojum proof system upgrade How to become a more secure and efficient zkEVM?

zkSync Boojum proof system upgrade and achieving a more secure and efficient zkEVM

Written by: zkSync

Compiled by: Deep Tide TechFlow


The mission of zkSync is to advance personal freedom for everyone by building a blockchain network that is trustless, secure, permissionless, cost-effective, user-friendly, scalable, and infinitely expandable, making digital self-ownership universally accessible.

To fulfill this mission, the Alpha version of zkSync Era was opened to the public over three months ago and the response has been incredible. Network highlights include:

  • Total Value Locked (TVL) of $577 million (source: L2Beat);

  • 23,750,000 transactions in the past 30 days— the highest among all L2 solutions (source: L2Beat);

  • 9,735 smart contracts verified with source code.

In March 2023, based on SNARK, zkSync Era was born, utilizing a battle-tested circuit framework that has supported zkSync Lite on the mainnet for nearly three years. However, we knew this would not be the final version of the zkSync Era proof system, so we designed it in a way that allows us to make fundamental changes without regeneration. This means we can deploy significant cryptographic upgrades without disrupting developers and users.

Behind the scenes, we have been working on cryptographic upgrades for a long time. Today, we are pleased to announce the first upgrade: zkSync Era is transitioning to a new STARK proof system called “Boojum”.

Meet Boojum

Boojum is an arithmetic and constraint library developed by us in Rust, which we use to implement the upgraded versions of zkSync Era and ZK Stack ZK circuits.

What is Boojum?

Features of Boojum:

  • PLONK Arithmeticization: In the context of zero-knowledge protocols, arithmeticization is the process of transforming general computations into mathematical form. Like the current proof system, the upgraded system still adopts PLONK-style arithmeticization. This approach simplifies the writing of ZK circuits compared to some alternative forms, making the system easier to develop, audit, maintain, and upgrade.

  • Powerful Commitment Scheme: The core of Boojum is the FRI commitment scheme, a key component that allows us to commit to bounded polynomials and subsequently efficiently prove that the claimed opening of the polynomial indeed belongs to a low-degree polynomial.

  • Efficiency of the System: Although witness generation is sometimes overlooked when discussing prover performance, in the current version of the proof system, we have achieved highly efficient GPU provers to the extent that witness generation time is comparable to proof generation time. With Boojum, we provide witness generation with automatic parallelization (if the dependency graph allows) while maintaining the simplicity of defining witness generation functions.

  • Easy Scalability: The basic constraint system abstraction is very concise, but it allows users to add custom gate types in various ways, such as adding specialized polynomials or reusing so-called “universal columns”. After defining simple geometric structures for their circuits, users can use the extension interface to automatically generate provers, verifiers, and recursive verifiers, enabling a highly efficient development process. If users change the circuit structure and choose different types of gates to use, they only need to call the interface again, which will regenerate the keys and ensure they use the correct provers and verifiers.

  • Single Stack: Through Boojum, all of the above can be expressed using standard, idiomatic Rust, leveraging the expressive power of its type system. The compute-intensive part of the GPU prover is written in CUDA C++, but we provide Rust bindings for composition.

Boojum uses a prime field of size 2^64 – 2^32 + 1 (known as the “Goldilocks field”) by default, and provides implementations of corresponding field binding primitives, such as the Poseidon2 hash function, and implementations of more standard cryptographic primitives based on lookup tables, such as SHA256, Keccak256, and Blake2s.

Importantly, in the final step, we will use an opaque pair-based SNARK to wrap the STARK proof and verify this SNARK on Ethereum. This proof is much smaller and has lower verification costs; this step reduces the cost of the proof system, thereby reducing the cost of the transaction itself.

Why choose Boojum?

When designing Boojum, there were two key factors behind the decisions: (1) world-class proof performance, and (2) reducing the hardware requirements for decentralization.

World-class performance

Current SNARK-based systems, while effective for the present, cannot scale to high transaction volumes and near-real-time transactions in the ZK Stack. The future goal of Hyperchain running zkSync Era is to support these systems in the coming years. Our vision for these systems is that proofs can be generated and verified cheaply and quickly, enabling fast finality and interoperability with Hyperchain.

The performance of the proof system directly affects the cost users pay for their transactions, and over time, these costs need to approach zero. The current version of the proof system is efficient enough to build zkEVM and process millions of transactions in just a few months, but with Boojum, we can do even better!

To measure the proof generation time of the network (as well as other key performance metrics), we collaborated with Celer, a team with extensive experience in benchmarking and analyzing multiple proof systems. In the image below, you can see that Boojum performs well in most of the systems analyzed for performance. The results speak for themselves: our implementation demonstrates world-class proof performance and is currently the fastest proof system in production use to the best of our knowledge.

For a fair comparison, Celer conducted these benchmarks on CPU-based provers, but our mainnet system uses GPU-based provers, which are faster.

Transitioning to a STARK-based proof system represents a significant performance improvement and will help ensure low latency for finality and increased activity levels for zkSync Era and other ZK Stack-based systems.

Reducing the hardware requirements for decentralization

These performance results are particularly impressive when one considers that this is not the only metric we optimize for – we want to improve system performance while reducing the hardware requirements to run it.

Currently used proof systems, including our existing system, have high hardware requirements. Our current proof system runs on a set of A100 GPUs, with each GPU having 80 GB of RAM. The demand for expensive and powerful machines poses a significant obstacle to our goal of user-driven decentralized proof generation in the future. To achieve this goal, it is not enough to make proof generation permissionless; users should not need an expensive machine with hundreds of GBs of RAM to participate.

This is another area where we have made remarkable progress! Our GPU prover for Boojum only requires 16 GB of RAM, which is a significant step towards the low threshold we envision for the future. CPU-based provers can also be used with as little as 64 GB of RAM, and we hope to reduce that to 32 GB while making full use of modern multi-core processors.

Finally, the Rust-based serializer for zkSync Era is already capable of processing over 100 transactions per second (TPS). The introduction of the new proof system not only improves performance but also reduces hardware requirements, making it an ideal complement to the serializer. The performance boost brought by Boojum means that transactions can be proven faster, while the reduced hardware requirements improve network access to cheaper machines for higher scalability.

The Journey of Boojum’s Mainnet

The team has spent months developing this upgrade, and we are excited to now be at the stage of testing the system on the mainnet. We also want to share some stories from the journey so far.

Upgrading zkSync Era

First, the design of zkSync Era allows us to upgrade each component over time, and the proof system is no exception.

Similar to Ethereum, we use a Merkle tree data structure to store information about the network state. Given that we are proving statements about the system state, this information is necessary for the proof system. For this Merkle tree (and the way the proof system interacts with it), a key design decision is the use of non-archival hash functions, specifically Blake2s. If we were optimizing only for the convenience of proof generation, we would use archival hash functions (such as Poseidon2), but this choice couples the observable state with the proof system parameters—for example, the choice of prime field. Then, any upgrade to the proof system would require a complete regeneration of the state.

From Design to Audit: The Journey of Boojum

About a month ago, we began to gradually form a complete end-to-end version of our new proof system implementation. Given the complexity of this change and the criticality of system correctness, we started a series of internal and external audits.

At the time, the zkEVM circuit and the Boojum arithmetic library were still actively under development, but we worked with external security auditors, focusing on early identification of soundness issues in our main circuits and Boojum components. We collaborated closely, providing them with full access to source code and documentation, and they reviewed and tested the zkEVM circuit and Boojum tools using a combination of automated and manual testing.

Boojum: From Audit to Testing

This brings us to today, the next step we are rolling out in phases: Mainnet Shadow Mode! We are excited to announce that we are now running the new proof system in parallel with the existing proof system, even though Boojum is currently in a testing phase. We have started generating and validating “shadow proofs” for mainnet blocks.

These shadow proofs are not necessary for the mainnet version of zkSync Era—it will still be driven by the existing proof system. We are simply verifying these shadow proofs to further test and optimize the system, but using real production data from zkSync Era user activity.

Boojum: From Testing to Mainnet

As with everything we do, security is always a top priority. We will only consider migration when we are fully satisfied with the testing of the new system, and we will share more details in the coming weeks and months. We also plan to conduct further audits and security assessments to bring this exciting upgrade closer to full deployment and gradually phase out the current proof-of-stake system.

We believe that Boojum represents the next stage of zkEVM that is more secure, scalable, and efficient.