ZKsync OS

What are we actually proving?

The most useful mental model is not “a blockchain that happens to use ZK.” It is a state-transition machine whose execution is turned into a proof of correct computation.

How money flows in ZKsync OS

Separate the user's fee, the operator's costs, and the assets represented by the rollup state. They are related, but they are not the same accounting object.

Pubdata is not “just gas”

Pubdata is the information needed to make the rollup's state transition reconstructible/verifiable on L1. Depending on the protocol design and era, this can include compressed transaction/state-diff information and commitments. The security question is: does the data committed on L1 correspond to the state transition actually proven?

Sequencer → Ethereum

The operator therefore has an economic stack underneath execution: L1 publication costs, proving costs, infrastructure, storage, networking and operational overhead. The exact fee schedule and who bears each cost must be read from the current ZKsync protocol implementation rather than inferred only from the diagram.

Execution → witness → proof

Airbender's current architecture uses a RISC-V 32I+M proving machine with DEEP-STARK/FRI arguments, lookup/RAM/delegation arguments and AIR constraints. The repository describes proving in chunks, connecting chunks with global RAM and delegation arguments, and then joining them through recursion.

Bridge flow

Historically, ZK rollups are described as holding funds in an L1 smart contract while computation and storage happen off-chain, with validity proofs used to establish correct state transitions.

Do not confuse ZKsync OS with Airbender

These are two connected but different layers. ZKsync OS is the generalized RISC-V-based state-transition implementation. Airbender is the proving system that proves execution of RISC-V programs. The official ZKsync OS repository lists components such as zk_ee, basic_bootloader, evm_interpreter, zksync_os_runner and forward_system.

Airbender's end-to-end documentation describes the flow from a RISC-V binary through proving, final proof generation, SNARK wrapping and verification.

Where the highest-value bugs live

The most dangerous class is a semantic mismatch: the execution engine says one thing while the proving circuit, verifier, or settlement layer accepts another.

Files to study first

Complex math — later

Study field arithmetic, FRI folding, quotient-polynomial generation and circuit optimization after the protocol lifecycle is clear. Otherwise it is easy to understand the mathematics without understanding what security property the mathematics is protecting.

Audit one invariant, not the whole repository

Pick one invariant and follow it through every layer. A strong starting point is:

fees credited == fees debited

Then search for every place that can affect it:

Then draw the real execution path

validate
   ↓
execute
   ↓
update state
   ↓
accumulate fees
   ↓
refund / settle
   ↓
commit / publish

At every transition ask: “What can still happen after something important has failed?”

Trace one boolean everywhere

Pick one control bit such as is_valid, verified, should_execute, commit or reverted. Follow its origin, transformations and consumers. Security bugs often hide where one subsystem assumes a boolean was already enforced by another subsystem.

What you should be able to prove

Read the implementation, not just the diagram

The current Airbender documentation describes the system as a RISC-V prover with AIR, lookup/RAM/delegation arguments, chunked proving and recursion. The separate prover-service repository provides FRI and SNARK prover services.