Overview

ZKsync OS is the modular execution layer of the ZKsync stack. It defines the system-level state transition function of a chain and supports multiple execution environments (VMs).

Unlike earlier implementations, ZKsync OS separates execution from proving, making both layers independently upgradable and easier to optimize. This design improves performance, ensures EVM equivalence, and enables new execution environments to be added for application-specific use cases.

Architecture

The core of the protocol is built around a two-layer architecture:

• a modular execution layer,
• and the proving layer.

The execution layer defines the logic of execution, memory handling, and IO. It takes block data and an initial state as input and computes the new state after the block is applied. The proving layer then generates validity proofs of this state transition.

ZKsync OS is implemented in Rust and compiled to two targets. The x86 target is used by the sequencer to run execution directly, while the RISC-V target is provided to the ZKsync Airbender prover to generate proofs of correctness. This ensures consistency between the sequencer’s runtime behavior and the proof system, while keeping execution and proving cleanly separated.

By isolating these layers, ZKsync OS makes it possible to evolve execution logic independently from the prover. This separation also shifts focus to the execution layer, an area often neglected in rollup design. While many efforts in the ecosystem concentrate on prover efficiency, ZKsync OS demonstrates that significant performance gains can also be achieved by optimizing how execution itself is structured.

Components of ZKsync OS

The main components of ZKsync OS are:

1. Bootloader: The entry point program. It initializes the system and then runs transactions using two components: the system and the execution environment interpreters.
2. Execution Environments: Regular interpreters that take bytecode, calldata, resources (similar to gas) and some other call context values as its input. Interpreters are instantiated with some local state to execute a frame. When an interpreter sees a call to another contract, return/revert from current frame, or contract creation it triggers special functionality to process it, as a potentially different interpreter should be run.

ZKsync OS will initially only support EVM. In the future, it will include the following EEs:

• EVM: Provides full native EVM-equivalence to ZKsync.
• WASM: Allows ZKsync to support contracts written in any language that compiles to WASM (e.g. Rust).
• Native RISC-V: User-mode RISC V code execution unlocks highest proving performance due to not having any interpretation overhead.

3. System: Common for all environments and the bootloader. Provides an abstract interface for low level handling of IO (storage, events, L1 messages, oracles) and memory management. The system communicates with the external oracle (non-determinism source), which is needed to read block data, and also for some IO operations, e.g. to perform the initial read for a storage slot.

This modular design enables us to isolate a minimal interface required to implement an Execution Environment. In addition, the system abstraction makes the storage model customizable and allows for different instances of the entire system.

System Design Goals

The design of ZKsync OS focuses on delivering high throughput and low cost. The Rust implementation enables low-level optimizations for memory access, IO, and execution paths, ensuring that performance can scale in line with network demands.

ZKsync OS serves as the foundation of the Elastic Network. For builders, it offers full EVM equivalence and tooling, while also unlocking new programming models through WASM and RISC-V.

For users, ZKsync OS provides a consistent experience across chains, with security underpinned by ZK proofs. And for the broader ecosystem, its modular design allows for application-specific specialization without fragmentation, while maintaining interoperability across all ZKsync Stack chains.