zkVM projects are currently suffering from "Version Hell," where each project must individually fork and modify programming language toolchains. The current structure requires repeated modifications every time a new version is released, and security patches must be manually applied to each fork, resulting in massive resource waste and inherent security risks.
Researchers from LayerZero Labs and Stanford University propose ZeroOS as a solution to this problem. Instead of modifying the internals of each language, ZeroOS takes an approach that modifies the system call interface layer that all languages commonly use. This allows developers using zkVMs to use unmodified standard toolchains as-is, eliminating the burden of version management.
When all zkVM projects share the same ZeroOS code, a single security audit or performance improvement can immediately propagate across the entire ecosystem. Individual projects will be able to focus on developing their own core technologies instead of maintaining toolchains.
2025 has been the year when zero-knowledge virtual machine (zkVM) projects began delivering tangible results. Starting with major projects like Succinct and Boundless successfully launching their mainnets, more than twenty teams are now competing in this space. (Source: Ethproofs)
However, despite this progress, a significant structural inefficiency remains in the zkVM ecosystem: the toolchain maintenance nightmare known as "Version Hell."
Let's illustrate a simple example of how Version Hell occurs.
Imagine a zkVM project that wants to support developers running programs written in the Rust programming language on their platform. At first glance, it seems like a simple task of just using the Rust compiler. However, reality is not so straightforward. The core components of Rust must be individually modified to fit the special execution environment of a zkVM. It's similar to having to modify the power plug of an appliance imported from another country to fit domestic outlets. The problem is that this "modification" is not a simple adapter connection but rather work at the level of tearing apart and rebuilding the internal circuitry itself.
Therefore, the project team ends up copying the internal code of a specific Rust version (for example, version 1.69) and creating their own modified version. This seems fine up to this point, but as time passes, the real problems begin. Rust continues to evolve with new versions, adding new features and security fixes. Customers naturally want to use these new features, so the project must repeat the same modification work for each new version. If they also need to support another programming language, they must perform the same work for multiple versions of that language as well.
The number of modified versions branching out by language and version grows exponentially, and the burden of managing each one separately snowballs. To make matters worse, when a serious security vulnerability is discovered in the original language and an emergency fix is released, the project team must manually apply this fix to every fork version they maintain. Users remain exposed to known vulnerabilities until this work is completed. Since nearly every zkVM project in the ecosystem faces this situation individually, from an industry-wide perspective, this represents massive resource waste and serious security risk.
Source: LayerZero
To address this problem at a fundamental level, researchers from LayerZero and Stanford University collaborated to propose ZeroOS, announced today on December 12, 2025. Instead of modifying the internals of each programming language one by one, the proposal is to make modifications just once at a deeper layer that all languages commonly depend on: the interface where the operating system and programs communicate. This way, all languages and all zkVM platforms above it automatically benefit.
To understand more deeply why ZeroOS is needed, we first need to examine what possibilities zkVM technology opens up.
When we use computers in daily life, in most cases we accept "whether this program worked correctly" based on trust. When a banking app displays that a transfer has been processed, we simply believe it. This trust is based on the reputation of the company that made the program, government regulations, or simply the experience that "it has worked without problems until now." For most situations, this level of trust is sufficient, but sometimes stronger guarantees are needed.
Zero-Knowledge Proofs exist precisely for such situations. Using this technology, one can mathematically prove that a computation was performed correctly. To explain with an analogy: suppose you claim to know the answer to a complex math problem. The traditional method is to show the solution process from beginning to end, but this exposes all your solving techniques. With zero-knowledge proofs, however, it becomes possible to keep the solution process secret while still proving with 100% certainty to the other party that "this person definitely knows the answer."
A zkVM applies this technology to general computer programs. Think of it as a virtual computer that mathematically proves that a program was executed correctly for a given input. Through a zkVM, the integrity of results output by a program and the company that created it can be mathematically verified.
This is where the gap between ideal and reality appears. zkVMs are often described as being able to "prove anything as long as it's a program that runs on a regular computer," but this is not so simple at the actual implementation level. Modern programs constantly communicate with a behind-the-scenes helper called the operating system to execute.
For example, when a program requests "I need memory" or "please save this file," the operating system handles the complex work behind the scenes. However, since a zkVM is essentially closer to an empty environment without an operating system, bringing a regular program directly means these requests won't be processed, causing the program to either not work or stop midway.
The solution until now has been to tear apart the internals of each programming language and replace the parts that request help from the operating system with code that handles things directly in the zkVM environment. This has given rise to the Version Hell problem mentioned earlier.
The core of ZeroOS starts from the fact that computer software is structured in stacked layers.
It's easy to understand by comparing the process of running a program on a computer to a building. On the top floor are the applications we directly use. Below that are the basic tools provided by programming languages. Further down are the foundational tools that all languages commonly use. At the very bottom sits the operating system. Upper floors always depend on services provided by lower floors.
The existing approach was to make modifications at the layer where each programming language's basic tools reside, the second floor from the top. The problem with this approach was that each language has completely independent designs and implementations, requiring modification work to be done from scratch each time. It was like having to do separate plumbing work for each office in a building.
ZeroOS goes one floor deeper, working at the boundary between the foundational tools layer that all languages commonly use and the operating system. This boundary is technically called the "system call (syscall)" interface. Simply put, it's the standardized gateway that programs use when requesting something from the operating system. Whether a program is written in Rust or C, if it needs memory, it ultimately makes the request through this gateway. ZeroOS plays the role of receiving and processing requests at this very gateway.
The advantages of this approach are highly intuitive. Using the plumbing analogy mentioned earlier, instead of fixing the plumbing in each office one by one, it's like installing a central plumbing system for the entire building just once. When the central system works properly, all offices automatically benefit. Moreover, this central system's interface has been operating stably for decades and has barely changed. Looking at the example cited in the paper, when the operating system's memory management features were expanded in 2001, compatibility with the existing interface was perfectly maintained. This demonstrates how stable the interface at this layer is.
As a result, using ZeroOS allows developers to use unmodified standard programming tools as-is. When a new version comes out, just use it. When a security patch is released, apply it immediately. Version Hell disappears.
ZeroOS technically belongs to the category of "library operating systems." Understanding what this means makes ZeroOS's design philosophy clearer.
The operating systems we commonly use, such as Windows, Mac, and Linux, are equipped with numerous features to prepare for all possible situations. Network communication, file management, screen output, keyboard input, simultaneous execution of multiple programs: almost every feature imaginable is included. While this approach is reasonable for general-purpose computers, it causes serious waste in zkVM environments.
To understand why, you need to know the unique cost structure of zkVMs. When a program runs on a zkVM, every action the program performs is recorded without exception. Based on this record, a mathematical proof is created that "this program was executed correctly." The key point is that the longer the record, the more time and cost it takes to create the proof. Therefore, in a zkVM environment, each unnecessary action directly translates to actual monetary cost.
If a program performs purely numerical calculations and never uses network communication, there's no reason for network-related features to be included in the program. Even if they're not used, once they're included, unnecessary actions get recorded during the initialization process, which can lead to increased proof costs.
ZeroOS's library operating system design solves this problem in a modular way. Operating system features are separated into individual components like Lego blocks, allowing you to select and assemble only the parts you need when building a program. If you don't need networking, remove the network component. If you don't need complex memory management, choose a simpler version of the memory management component. The paper calls this a "Pay-for-what-you-use" model.
The advantages of this model extend beyond efficiency. There are also significant benefits from a security perspective. The less code included in a program, the fewer places where bugs or security vulnerabilities can hide. From a program developer's standpoint, they only need to trust the components they actually use, and they can be confident that even if there are serious problems with unused components, their program won't be affected.
To feel this difference in concrete numbers: the data structure that manages the basic unit of program execution in a general operating system contains more than 300 information items. These are necessary for managing complex environments where multiple users run multiple programs simultaneously. In contrast, the data structure serving the same role in ZeroOS has only three information items. In a zkVM environment where only one program runs, everything else is unnecessary. This kind of extreme simplification is the essence of ZeroOS's design.
The most important change that ZeroOS will bring is thought to lie in the dynamics shift across the entire ecosystem rather than in technical advancement alone.
Security auditing, the work of verifying software security, is a very expensive task. Skilled security experts must review code line by line to find vulnerabilities. In the forked toolchain model, each zkVM project must perform this work separately for the code they've modified. Even if Project A has their modified version audited, the results don't apply to Project B because the modifications differ. From an industry-wide perspective, more than twenty redundant audits are being performed on similar code.
In the ZeroOS model, the situation changes completely because all zkVM projects share the same ZeroOS code. A single audit result applies to all projects, and a vulnerability fix discovered in one place propagates simultaneously to everywhere. Borrowing the paper's expression, the level of security is no longer determined by how much individual teams can invest in audits, but by the resources the entire ecosystem invests collectively.
The same logic applies to performance improvements. If someone discovers a way to improve ZeroOS's memory management efficiency by 10%, that benefit immediately propagates to all zkVMs using ZeroOS and all programs running on top of them. Since developers from more than twenty projects and countless applications being developed on top of them can potentially contribute to this shared code, there's also the effect of concentrating improvement efforts that were previously scattered into a single codebase.
Joining this ecosystem becomes much easier for new zkVM projects as well, because the code that must be implemented differently for each platform has been minimized to just a single function. By implementing only this function to fit their platform, they can use all of ZeroOS's other features as-is. New projects can focus on their own differentiated technologies instead of the draining work of version management.
When a new technology field emerges, there's initially a period when everything must be built from scratch. Competition is fierce and there are no standards, so everyone solves the same problems in their own way. However, as technology matures, at some point a common foundation emerges. Just as the era when every website wrote its own network communication code gave way to shared libraries, the zkVM ecosystem appears to have reached such a turning point.
What ZeroOS proposes is competition on top of a shared foundation. Each zkVM project can pursue differentiation through its own proof technology, its own optimization methods, and its own user experience, but the fundamental problem of compatibility with programming languages is solved together. zkVM development teams can escape the yoke of toolchain maintenance and focus on core technologies. Application developers can use familiar tools and libraries as-is. End users will encounter safer and more trustworthy programs.
An era of verifiable computing, where mathematical proofs replace trust, is approaching. ZeroOS presents one compelling answer to what the operating system of that era should look like.
Dive into 'Narratives' that will be important in the next year
LayerZero
Gradient
IOTA