ZeroOS: A Universal Modular Library OS for zkVMs
zkVMs promise general-purpose verifiable computation through ISA-level compatibility with modern programs and toolchains. However, compatibility extends further than just the ISA; modern programs often cannot run or even compile without an operating system and libc. zkVMs attempt to address this by maintaining forks of language-specific runtimes and statically linking them into applications to create self-contained unikernels, but this ad-hoc approach leads to version hell and burdens verifiable applications (vApps) with an unnecessarily large trusted computing base. We solve this problem with ZeroOS, a modular library operating system (libOS) for vApp unikernels; vApp developers can use off-the-shelf toolchains to compile and link only the exact subset of the Linux ABI their vApp needs. Any zkVM team can easily leverage the ZeroOS ecosystem by writing a ZeroOS bootloader for their platform, resulting in a reduced maintainence burden and unifying the entire zkVM ecosystem with consolidated development and audit resources. ZeroOS is free and open-sourced at https://github.com/LayerZero-Labs/ZeroOS.
💡 Research Summary
ZeroOS is a universal modular library operating system (libOS) designed for zero‑knowledge virtual machines (zkVMs) to simplify the creation of verifiable applications (vApps). Current zkVM ecosystems achieve ISA‑level compatibility but lack OS and libc support, forcing each platform to maintain forked, language‑specific toolchains that statically link custom runtimes into unikernels. This approach creates “version hell,” inflates the trusted computing base (TCB), and scatters security‑audit effort across dozens of divergent codebases.
ZeroOS replaces these ad‑hoc patches with a single, language‑agnostic syscall shim. By intercepting the system‑call instruction (e.g., ECALL on RISC‑V) and dispatching it to a generic kernel, ZeroOS lets developers compile their applications with unmodified off‑the‑shelf toolchains (gcc, clang, rustc, etc.) and simply link against the ZeroOS bootloader and kernel. No changes to libc or language runtimes are required, eliminating the need for per‑language forks.
The architecture consists of three layers:
-
Build Config – a lightweight configuration that bridges the existing compiler/linker to the ZeroOS kernel. It lives in build scripts (e.g., musl‑toolchain.sh) and does not modify the compiler source, preserving standard compliance and portability.
-
Bootloader – a platform‑specific entry point that performs CPU, memory, and device initialization, loads the ZeroOS runtime (musl‑based libc) and kernel, then transfers control to the application. Each zkVM only needs to implement a single function
__platform_bootstrap; all other components remain platform‑agnostic. -
Kernel – a modular set of syscall handlers, wrappers, and primitive operation registries (memory_operations, scheduler_operations, etc.). Each syscall wrapper can be enabled or disabled at compile time, allowing developers to “unplug” unused functionality such as I/O, ioctl, or networking. Memory allocation, for example, can be swapped between a simple freelist, a buddy allocator, or any custom module without changing application code.
ZeroOS’s modularity yields two major benefits. First, the TCB is dramatically reduced: only the kernel and selected modules are trusted, while language runtimes stay untouched and inherit the security guarantees of the upstream ecosystem. Second, the “pay‑for‑what‑you‑use” model shortens the execution trace recorded by the zkVM prover, directly lowering the cost of generating succinct proofs (SNARKs/STARKs). Because zkVM provers must record every instruction, eliminating unused syscalls reduces both memory footprint and verification time.
Determinism—a strict requirement for zkVMs—is enforced by keeping all state‑changing operations inside the kernel and exposing external inputs (entropy, timestamps) through explicit, deterministic interfaces. This prevents a malicious prover from influencing the trace in ways that could compromise application safety.
From a security‑operations perspective, ZeroOS consolidates audit and patching effort. Instead of maintaining dozens of language‑specific forks, a single security audit of the ZeroOS kernel benefits every zkVM and every vApp that adopts it. Patches to memory allocators, scheduler logic, or syscall handling propagate instantly across the entire ecosystem, dramatically shrinking vulnerability windows.
The project is open‑source under the MIT license and hosted at https://github.com/LayerZero-Labs/ZeroOS. The repository includes the runtime libc (ZeroOS‑runtime‑musl), architecture‑specific bootloader (ZeroOS‑arch‑riscV), syscall ABI definitions, core wrappers, and a collection of optional modules (e.g., different allocators, device drivers). zkVM teams can integrate ZeroOS by providing only the __platform_bootstrap implementation for their platform, after which they can compile any existing application into a verifiable unikernel without further modifications.
In summary, ZeroOS offers a clean, language‑agnostic, and modular OS layer for zkVMs that eliminates version fragmentation, reduces the trusted code base, and improves proof efficiency. By unifying the OS interface across all zkVM projects, it paves the way for broader adoption of zero‑knowledge verifiable computation and more secure, maintainable vApps.
Comments & Academic Discussion
Loading comments...
Leave a Comment