|
1 | 1 | --- |
2 | 2 | title: Overview |
3 | | -description: Get started learning about ZKsync OS. |
| 3 | +description: Learn about the ZKsync OS Developer Preview testnet and its architecture. |
4 | 4 | --- |
5 | 5 |
|
6 | | -ZKsync OS is the modular execution layer of the ZKsync stack. It defines the system-level state transition function of a chain |
7 | | -and supports multiple execution environments (VMs). |
| 6 | +The **ZKsync OS Developer Preview** testnet is a new environment that runs on the latest architecture introduced in the [**Atlas upgrade**](https://zksync.mirror.xyz/XrlYJN9SUbOtRn9nyqrfPyaAqot--PlUcnSRK_OF1Bs). |
| 7 | +It includes all major components released in that upgrade — **ZKsync OS**, the **new Sequencer**, and the **Airbender prover** — giving developers |
| 8 | +early access to the full next-generation ZK Stack. |
8 | 9 |
|
9 | | -Unlike earlier implementations, ZKsync OS separates execution from proving, |
10 | | -making both layers independently upgradable and easier to optimize. This design improves performance, ensures EVM equivalence, and enables |
11 | | -new execution environments to be added for application-specific use cases. |
| 10 | +This testnet allows builders to deploy contracts, profile system performance, and explore how the ZK Stack has |
| 11 | +evolved across execution, sequencing, and proving. |
12 | 12 |
|
13 | | -## Architecture |
14 | | - |
15 | | -The core of the protocol is built around a two-layer architecture: |
| 13 | +--- |
16 | 14 |
|
17 | | -- a modular execution layer, |
18 | | -- and the proving layer. |
| 15 | +## Overview |
19 | 16 |
|
20 | | -The execution layer defines the logic of execution, memory handling, and IO. It takes block data and an initial state as input |
21 | | -and computes the new state after the block is applied. The proving layer then generates validity proofs of this state transition. |
| 17 | +**ZKsync OS** is the new operating system of the ZK Stack. |
| 18 | +It defines the system-level state transition function of a chain and supports multiple **Execution Environments (EEs)**. |
22 | 19 |
|
23 | | -ZKsync OS is implemented in Rust and compiled to two targets. The **x86 target** is used by the sequencer to run execution directly, |
24 | | -while the **RISC-V target** is provided to the ZKsync Airbender prover to generate proofs of correctness. This ensures consistency between |
25 | | -the sequencer’s runtime behavior and the proof system, while keeping execution and proving cleanly separated. |
| 20 | +Unlike earlier implementations, ZKsync OS unifies **execution and proving logic** in one codebase and compiles it to two targets — **x86** for |
| 21 | +the sequencer runtime and **RISC-V** for the Airbender proving system. |
26 | 22 |
|
27 | | -By isolating these layers, ZKsync OS makes it possible to evolve execution logic independently from the prover. |
28 | | -This separation also shifts focus to the execution layer, an area often neglected in rollup design. While many efforts |
29 | | -in the ecosystem concentrate on prover efficiency, ZKsync OS demonstrates that significant performance gains can also be |
30 | | -achieved by optimizing how execution itself is structured. |
| 23 | +The Developer Preview testnet runs **ZKsync OS alongside the new Sequencer and Airbender prover**, providing a complete |
| 24 | +environment for testing the latest stack. |
31 | 25 |
|
32 | | -## Components of ZKsync OS |
| 26 | +--- |
33 | 27 |
|
34 | | -The main components of ZKsync OS are: |
| 28 | +## Architecture |
35 | 29 |
|
36 | | -1. **[Bootloader](/zksync-protocol/zksyncos/bootloader):** The entry point program. It initializes the system and then runs transactions using two |
37 | | -components: the system and the execution environment interpreters. |
| 30 | +The core protocol is organized into two primary layers: |
38 | 31 |
|
39 | | -2. **[Execution Environments](/zksync-protocol/zksyncos/execution-environment):** Regular interpreters that take bytecode, |
40 | | -calldata, resources (similar to gas) and some other call context values as its input. Interpreters are instantiated with some local state to execute |
41 | | -a frame. When an interpreter sees a call to another contract, return/revert from current frame, or contract |
42 | | -creation it triggers special functionality to process it, as a potentially different interpreter should be run. |
| 32 | +- **Execution layer:** defines transaction logic, memory handling, and IO. It computes new state from the previous block state and inputs. |
| 33 | +- **Proving layer:** generates ZK proofs that attest to the correctness of that state transition. |
43 | 34 |
|
44 | | -ZKsync OS will initially only support EVM. |
45 | | -In the future, it will include the following EEs: |
| 35 | +ZKsync OS is implemented in **Rust** and compiled to two targets: |
46 | 36 |
|
47 | | -- **EVM:** Provides full native EVM-equivalence to ZKsync. |
48 | | -- **WASM:** Allows ZKsync to support contracts written in any language that compiles to WASM (e.g. Rust). |
49 | | -- **Native RISC-V:** User-mode RISC V code execution unlocks highest proving performance due to not having any interpretation overhead. |
| 37 | +- **x86:** used by the Sequencer to execute transactions |
| 38 | +- **RISC-V:** used by the Airbender prover to generate ZK proofs of correctness |
50 | 39 |
|
51 | | -<!-- markdownlint-disable --> |
52 | | -3. **[System](/zksync-protocol/zksyncos/system):** Common for all environments and the bootloader. Provides an abstract interface for low level |
53 | | -handling of IO (storage, events, L1 messages, oracles) and memory management. The system communicates with the |
54 | | -external oracle (non-determinism source), which is needed to read block data, and also for some IO operations, |
55 | | -e.g. to perform the initial read for a storage slot. |
| 40 | +This “one program, two targets” model ensures *what you execute is what you prove*, eliminating discrepancies between |
| 41 | +runtime and proof generation and reducing the audit surface. |
| 42 | +Execution and proving operate as **decoupled services** (sequencer vs. prover) while sharing the exact same program and semantics. |
56 | 43 |
|
57 | 44 | ::centered-container |
58 | 45 |  |
59 | 46 | :: |
60 | 47 |
|
61 | | -This modular design enables us to isolate a minimal interface required to implement an Execution Environment. |
62 | | -In addition, the system abstraction makes the storage model customizable and allows for different instances of the entire system. |
| 48 | +--- |
| 49 | + |
| 50 | +## Components |
| 51 | + |
| 52 | +### ZKsync OS |
| 53 | + |
| 54 | +The core of the system. |
| 55 | +ZKsync OS provides a modular execution framework that supports multiple execution environments and defines the rules for state transitions. |
| 56 | + |
| 57 | +- **[Bootloader](/zksync-protocol/zksyncos/bootloader):** initializes the system and coordinates transaction execution. |
| 58 | +- **[Execution Environments](/zksync-protocol/zksyncos/execution-environment):** interpreters that run user contracts and system logic. |
| 59 | +- **[System Layer](/zksync-protocol/zksyncos/system):** handles low-level IO (storage, events, L1 messages) and manages memory. |
| 60 | + |
| 61 | +The Developer Preview currently supports a **fully EVM-equivalent environment**, allowing developers to use |
| 62 | +existing EVM tools (e.g. Foundry, Hardhat, solc) and deploy contracts without modification. |
| 63 | +Future versions may include **EraVM**, **WASM** and **native RISC-V** environments. |
| 64 | + |
| 65 | +Learn [more about ZKsync OS in the protocol documentation](../../zksync-protocol/zksyncos/overview). |
| 66 | + |
| 67 | +--- |
| 68 | + |
| 69 | +### Sequencer |
| 70 | + |
| 71 | +The new **Sequencer**, introduced as part of the [Atlas upgrade](https://zksync.mirror.xyz/XrlYJN9SUbOtRn9nyqrfPyaAqot--PlUcnSRK_OF1Bs), is designed for: |
| 72 | + |
| 73 | +- **High throughput** — sustained >15K TPS in ERC-20 transfer benchmarks |
| 74 | +- **Low latency** — sub-second inclusion, typically 250–500 ms |
| 75 | +- **Modularity** — clear separation of execution, API, and proving layers |
| 76 | + |
| 77 | +It offloads batching and L1 coordination to asynchronous services, simplifying the execution pipeline and improving resilience. |
| 78 | +For developers, this means faster transaction processing and easier scaling for custom ZK Stack chains. |
| 79 | + |
| 80 | +--- |
| 81 | + |
| 82 | +### Airbender Prover |
| 83 | + |
| 84 | +**Airbender** is the proving system used in the Developer Preview testnet. |
| 85 | +It is a general-purpose, open-source RISC-V zkVM integrated directly with ZKsync OS. |
| 86 | + |
| 87 | +Key properties: |
| 88 | + |
| 89 | +- **Efficient hardware utilization** — can run on a single GPU. |
| 90 | +- **Low cost** — proving an ERC-20 transfer costs roughly $0.0001. |
| 91 | +- **Fast proofs** — Airbender can be scaled horizontally to generate ~1 second block proofs and **minutes-to-Ethereum finality**. |
| 92 | + |
| 93 | +Because both execution and proving compile from the same Rust source, Airbender proves the exact code path executed by ZKsync OS. |
| 94 | +This reduces audit complexity and guarantees consistency between runtime and proofs. |
| 95 | + |
| 96 | +Learn [more about Airbender in the protocol documentation](../../zksync-protocol/zksync-airbender/overview). |
| 97 | + |
| 98 | +--- |
| 99 | + |
| 100 | +## Developer Preview Testnet |
63 | 101 |
|
64 | | -## System Design Goals |
| 102 | +The Developer Preview testnet includes: |
65 | 103 |
|
66 | | -The design of ZKsync OS focuses on delivering high throughput and low cost. |
67 | | -The Rust implementation enables low-level optimizations for memory access, |
68 | | -IO, and execution paths, ensuring that performance can scale in line with network demands. |
| 104 | +- **ZKsync OS** — modular execution layer with full EVM equivalence. |
| 105 | +- **New Sequencer** — redesigned high-performance execution engine. |
| 106 | +- **Airbender** — integrated real-time RISC-V prover. |
69 | 107 |
|
70 | | -ZKsync OS serves as the foundation of the Elastic Network. For builders, it offers full EVM equivalence and tooling, |
71 | | -while also unlocking new programming models through WASM and RISC-V. |
| 108 | +Developers can use this testnet to: |
72 | 109 |
|
73 | | -For users, ZKsync OS provides a consistent experience across chains, with security underpinned by ZK proofs. |
74 | | -And for the broader ecosystem, its modular design allows for application-specific specialization without fragmentation, |
75 | | -while maintaining interoperability across all ZKsync Stack chains. |
| 110 | +- Deploy and test contracts using familiar EVM tooling |
| 111 | +- Benchmark transaction throughput and latency |
| 112 | +- Integration test for infrastructure tools |
| 113 | +- Evaluate how the new architecture supports specific workloads |
0 commit comments