zkSync and Code4rena: securing Ethereum’s future with $1.1M in the Arena

zkSync is making a grand entry into the Arena, boasting a $1,100,000 USDC prize pool — the biggest audit Code4rena has ever run.

If you’ve been on the fence about getting into ZK/EVM/Yul, this is the nudge you’ve been waiting for!

Participating in this audit could be your game-changer, and we’re not just talking about the prizes on offer. This could be your dual golden ticket to be a part of both the thrill of innovation and recognition as a frontrunner in the ZK security world.

Don’t fret if you’re unfamiliar with Circom, Rust, or Moonmath, the contest covers more than just ZK Circuits: it will also cover Contracts, VM, and Compiler.

No matter your skill level, let’s dive into this article and gear you up for success.

What’s a ZK Rollup?

Put simply, a ZK roll-up is an L2 scaling solution. Instead of transacting directly on L1 itself, let’s say it creates a “parallel blockchain” that processes transactions completely separately.

Imagine you have a decentralized body of entities that will accept transactions and sequence them in blocks. That’s the sequencer.

The sequencer collects transactions and packs them into blocks that verifies if they’re valid because if they are invalid, they won’t be able to produce proofs.

When a block is finalized, two pivotal events occur:

1. Zero-knowledge proofs are computed for all the transactions in the block, and as a result, the final proof is produced, showing this block is complete

This involves a recursive proof generation, where each block is divided into smaller chunks, each validated separately before being aggregated into a single proof of the block, which contains all the logic required for that, e.g.:

• The transactions were executed correctly
• The user was authenticated
• The smart contract logic executed correctly

Then, it hashes all the computations.

The proof is then submitted to L1, accompanied by the new root hash for the block. This is akin to stating, “Here’s the updated state, the new commitment to that state, and the root hash. Additionally, here’s evidence that the new root hash is a valid transition from the previous one.”

Then, on L1, smart contracts have the capability to verify these proofs. Once verified, they confirm that the proof is correct and allow the state transition.

2. Even though the state transition is verified on L1, nobody else is aware of that (yet).

Hence, the next step is to keep everyone in the loop regarding the block’s latest events. Precisely, they need to understand the updated status of all the accounts; otherwise, everything would come to a frozen state.

Consider this scenario: If I can’t demonstrate to you that I possess money, then I can’t access or utilize it, making transactions on this chain impossible.

To address this, there’s a need to relay information to all observers. This is achieved by revealing the new state of the storage slot for the roll-up block, indicating any modifications made.

With this information, observers can piece together the state and proceed with the new block.

What’s a ZK proof?

A ZK Proof (Zero-Knowledge Proof) allows a verifier to ascertain that a prover has performed a computation accurately without revealing any other information.

In the context of zkSync, it facilitates the prover to demonstrate the proper execution of zkSync’s EVM. This proof is then validated by a smart contract on the Ethereum network.

The Proving Process

1. Witness Generation: zkSync processes new L2 blocks in batches, which are then forwarded to the circuits.
2. Circuits: To confirm the accurate execution of a virtual machine, a specific code, known as the ZK circuit, is utilized. This code is tailored for validation by the Proof System. For instance, separate circuits exist for every EVM opcode to validate each opcode’s correct execution.
3. Proof System: The ZK circuit requires a proof system for processing. zkSync employs a system named “Boojum” for this purpose.

Demystifying Circuits

Derived from Arithmetic Circuits, ZK circuits are typically interpreted by commencing at the base with the inputs and progressing upwards, computing each operation sequentially.

zkSync employs a technique termed PLONK for arithmetization of its circuits.

The prover

Within zkSync’s zk-rollup framework, the prover efficiently processes a collection of transactions executing smart contracts. It constructs proofs confirming the accuracy of all transactions and guarantees a seamless transition between states.

These proofs are then sent to a Verifier smart contract on Ethereum. In zkSync’s mechanism, the focus is on the state differences of a block of transactions to affirm the legitimacy of the new state root.

In essence, the prover ascertains that the circuit inputs satisfy every computational step, resulting in the desired output.

The Significance of Constraints

So, what exactly is a constraint? Simply put, it’s a stipulation or limitation governing certain operations.

zkSync incorporates constraints to verify specific operation’s legitimacy and during proof generation. If constraints are omitted, it could trigger glitches, whereas excessive constraints might overly restrict operations. Therefore, ensuring every operation adheres to appropriate constraints is crucial.

The prover should be compelled to compute precise values. A circuit lacking a constraint may enable a malicious prover to fabricate proofs that pass validation, even if they’re flawed.

As a consequence, an underconstrained circuit might cause a soundness error.

Security by design

zkSync’s system leverages Ethereum’s censorship-resistant attributes, using it as a foundation for data settlement and availability.

The system is modular

The system’s reliability isn’t solely based on the validity of the proofs. Initially, validators must have a consensus that a block is valid. Once agreed upon, they generate the zero-knowledge proofs.

A smart contract then checks both the majority of validators’ signatures and the zero-knowledge proof. Only when both criteria are satisfied does a state transition occur.

1. Isolation: Only blocks submitted by an authorized sequencer can commit state transitions
2. Redundancy: Every transaction proposed to the sequencer undergoes a basic execution validation before it’s added to a block.

This setup ensures that exploitation would be challenging even if there’s a flaw in the ZKP circuits or the foundational cryptography, and an invalid transaction’s zero-knowledge proof could be created.

Withdrawal delays

To mitigate the rapid depletion of the protocol in the event a significant bug is identified and manipulated, zkSync enforces a block execution delay. Every L2 block committed to L1 has a built-in time lock that must expire before the block is executed and finalized.

The Security Council:

A theoretical risk exists of encountering a bug that causes the zkEVM to malfunction internally, necessitating an immediate upgrade.

This is where the Security Council steps in. Their authority, however, is limited; they can only streamline and moderate this upgrade process.

Potential vulnerability areas to focus on

• Generating false proofs
• Circuit bugs that might permit arbitrary block proposals
• Introducing malicious blocks and feigning valid proofs
• Omitting constraints, potentially causing errors or oversights in circuits.

To wrap up

Whether you’re an experienced security researcher or merely a curious onlooker, the zkSync odyssey exemplifies the spirit of its evolution: bold, daring, and ceaselessly pushing toward a more efficient and secure future.

Don’t just observe history in the making; be a part of it! Participate in Code4rena’s biggest-ever audit in partnership with zkSync now.

See you in the Arena!

Thanks to bytes032 for this technical write-up.