Written by: zkSync

Compiled by: TechFlow

TLDR

• Upgrade: zkSync Era is transitioning to a new Boojum proving system without requiring re-generation.

• Performance: Boojum demonstrates state-of-the-art proving performance, complementing the zkSync Era sequencer which already handles over 100 TPS.

• Decentralization: Boojum provers require only 16 GB RAM, enabling large-scale decentralization of provers in the future.

zkSync's mission is to advance personal freedom for everyone—by building a trustless, secure, permissionless, affordable, easy-to-use, resilient, and infinitely scalable blockchain network that makes digital self-sovereignty universally accessible.

To fulfill this mission, the alpha version of zkSync Era was opened to the public over three months ago, with an overwhelmingly positive response. Network highlights:

• $577 million in total value locked (TVL) (source: L2Beat);

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

• 9,735 source-code-verified smart contracts.

In March 2023, the SNARK-based zkSync Era launched, leveraging a battle-tested circuit framework that had supported zkSync Lite on mainnet for nearly three years. However, we knew this would not be the final version of the zkSync Era proving system, so we designed it to allow fundamental changes without requiring re-generation. This means we can deploy major cryptographic upgrades without disrupting developers or users.

Behind the scenes, we've been working on cryptographic upgrades for a long time. Today, we are excited to announce the first upgrade: zkSync Era is transitioning to a new STARK proving system called "Boojum".

Introducing Boojum

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

What is Boojum?

Boojum features:

• PLONK arithmetization: In the context of zero-knowledge protocols, arithmetization is the process of transforming general computations into mathematical forms. Like the current proving system, the upgraded system still uses PLONK-style arithmetization. This approach simplifies ZK circuit development compared to some alternatives, making the system easier to develop, audit, maintain, and upgrade.

• Robust commitment scheme: At the core of Boojum lies the FRI commitment scheme—a key component allowing us to commit to bounded polynomials and then efficiently prove that claimed openings indeed belong to low-degree polynomials.

• System efficiency: Although witness generation is sometimes overlooked when discussing prover performance, in our current proving system we have optimized GPU provers to such an extent that witness generation time is comparable to proof generation time. With Boojum, we provide automatically parallelized witness generation (where dependency graphs allow), while preserving simplicity in defining witness functions.

• Easy extensibility: The base constraint system abstraction is very concise, yet allows users to add custom gate types in various ways—for example, by adding specialized polynomials or reusing so-called "generic columns". After users define a simple geometric structure for their circuit, the extension interface provides automatic generation of provers, verifiers, and recursive verifiers. This enables highly efficient development; if users modify the circuit structure or choose different gate types, they simply call the interface again, which regenerates keys and ensures correct prover and verifier usage.

• Unified stack: With Boojum, all of the above can be expressed using standard, idiomatic Rust, leveraging its expressive type system. The compute-intensive parts of the GPU prover are written in CUDA C++, but we provide Rust bindings for composition.

By default, Boojum uses a prime field of size 2^64 - 2^32 + 1 (known as the "Goldilocks field") and implements corresponding field-bound primitives such as the Poseidon2 hash function, as well as implementations of more standard cryptographic primitives based on lookup tables, including SHA256, Keccak256, and Blake2s.

Importantly, in the final step, we will wrap the STARK proof with a non-transparent pairing-based SNARK and verify this SNARK on Ethereum. This resulting proof is much smaller and cheaper to verify, reducing the overall cost of the proving system—and consequently lowering transaction costs.

Why Boojum?

Two key factors drove the design decisions behind Boojum: (1) world-class proving performance, and (2) reduced hardware requirements for decentralization.

World-Class Performance

The current SNARK-based system, while effective today, cannot scale to the high-throughput, near-instant transaction volumes envisioned for systems within the ZK Stack. zkSync Era’s long-term vision as a Hyperchain is to support these systems over the coming years. For these systems to succeed, proofs must be cheap and fast to generate and verify—enabling rapid finality and interoperability between Hyperchains.

Proving system performance directly impacts the fees users pay for transactions, which need to trend toward zero over time. While the current proving system is efficient enough to build a zkEVM and handle millions of transactions within months, Boojum allows us to do even better!

To measure proof generation time (and other key performance metrics), we partnered with Celer, whose team has extensive experience benchmarking and analyzing multiple proving systems. In the image below, you can see Boojum outperforming most competing systems across performance benchmarks. The results speak for themselves: our implementation demonstrates world-class proving performance—reportedly the fastest production-ready proving system currently available.

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

Transitioning to a STARK-based proving system represents a significant performance leap, helping ensure low-latency finality and support for growing activity levels on zkSync Era and other ZK Stack-based systems.

Lower Hardware Requirements for Decentralization

These performance results are especially impressive considering performance isn't the only metric we're optimizing—we aim to improve system performance while simultaneously reducing hardware requirements.

Currently widely used proving systems—including our existing one—have high hardware demands. Our current proving system runs on A100 GPUs, each equipped with 80 GB of RAM. The need for expensive, powerful machines poses a major obstacle to our goal: a user-driven, decentralized future for proof generation. Achieving this requires more than just making proof generation permissionless; users shouldn't need expensive machines with hundreds of gigabytes of RAM to participate.

This is another area where we’ve made remarkable progress! Our Boojum GPU prover requires only 16 GB of RAM—a low barrier that marks a crucial step toward our envisioned future. CPU-based proving can work with as little as 64 GB RAM, and we aim to reduce this further to 32 GB, fully leveraging modern multi-core processors.

Finally, zkSync Era’s Rust-based sequencer already handles over 100 transactions per second (TPS). Introducing the new proving system not only boosts performance but also lowers hardware requirements, making it an ideal complement to the sequencer. The performance gains from Boojum mean transactions can be proven faster, while reduced hardware needs improve accessibility to cheaper machines, enhancing horizontal scalability.

Boojum's Journey to Mainnet

The team has spent months developing this upgrade, and we’re excited to now enter the phase of testing the system on mainnet. We’d also like to share some of our journey so far.

Upgrading zkSync Era

First, zkSync Era was designed to allow upgrading every component over time, and the proving system is no exception.

Similar to Ethereum, we use Merkle tree data structures to store information about the network state. Since we're proving statements about system states, this information is essential to the proving system. A critical design decision for this Merkle tree (and how the proving system interacts with it) was to use a non-algebraic hash function—specifically Blake2s. If we were solely optimizing for ease of proof generation, we might have chosen an algebraic hash function like Poseidon2. But doing so would tightly couple the observable state to proving system parameters—such as the choice of prime field. Any upgrade to the proving system would then require full state regeneration.

From Design to Audit: Boojum's Journey

About a month ago, we began forming a complete end-to-end version of our new proving system implementation. Given the complexity of this change and the critical importance of system correctness, we initiated a series of internal and external audits.

At the time, the zkEVM circuit and Boojum arithmetization library were still under active development, but we collaborated with external security auditors to focus on early identification of potential soundness issues in our main circuit and Boojum components. We worked closely with them, providing full access to source code and documentation, as they reviewed and tested the zkEVM circuit and Boojum gadgets using both automated and manual testing methods.

Boojum: From Audit to Testing

This brings us to today and the next phase of our staged rollout: mainnet shadow mode! We are excited to announce that we are now running the new proving system in parallel with the existing one, although Boojum is currently in testing only. We have begun generating and verifying "shadow proofs" for mainnet blocks.

These shadow proofs are not required for the zkSync Era mainnet—they will continue to be powered by the existing proving system. We are merely validating these shadow proofs to further test and optimize the system, using real production data from zkSync Era user activity.

Boojum: From Testing to Mainnet

As with everything we do, security remains the top priority. We will only consider migration once we are fully satisfied with testing of the new system, and we’ll share more details in the coming weeks and months. We also plan additional audits and security assessments to bring this exciting upgrade closer to full deployment, gradually phasing out the current proving system.

We believe Boojum represents the next, safer, more scalable, and efficient stage for zkEVM.