Any product whose main selling point is technical features is a half-finished product.
Every product primarily marketed on technical features alone is incomplete.
The hype and debate around EVM and ZK-EVM have persisted for some time, especially since Vitalik categorized different types of ZK-EVMs. A flood of explanatory articles has emerged on concepts like bytecode, virtual machines, and compatibility—terms that remain poorly understood. What do these terms actually mean? And where will the widespread adoption of ZK-EVM lead the public blockchain landscape?
The ZK赛道 (ZK sector) has now officially heated up. If ZK-Rollups previously confined zero-knowledge technology to L2 solutions, it now shows signs of becoming a universal infrastructure across the entire blockchain ecosystem. R3PO believes that, to some extent, ZK-EVM could bring an end to the current multi-chain coexistence paradigm.
Throughout this transformative process, many new projects are bound to emerge. Committed to uncovering latent value, R3PO begins by intuitively understanding EVM to explore the future trajectory of public blockchains.

Image description: File transfer between different operating systems
Source: R3PO
Consider the following scenario:
Alice wants to send a Word document running on Windows to Bob, who only has a Mac capable of using Pages. Bob cannot open the file. How should this be resolved? Excluding the options of Bob installing Word for Mac or copying text content manually, four alternative methods remain:
1. Alice uploads the document to the cloud—e.g., Google Docs—and Bob can access and edit it via a cross-platform browser;
2. Alice sends both Word.exe and the document to Bob, who uses Crossover or a virtual machine (VM) to simulate a Windows environment, enabling .exe applications to run on Mac;
- Crossover supports only specific .exe applications like Word.exe, but not others;
- A VM installs a full Windows subsystem within Mac, allowing any .exe application to run inside it;
3. Alice converts the document into a format readable by Java and sends it; Bob installs a Java environment on Mac to open it;
4. Alice converts the document into binary format and transmits it; Bob opens it using the most fundamental level of compatibility.
If you understand this analogy, consider the following conceptual mappings:
- Operating systems like Windows and macOS → Public blockchains like Ethereum and Cosmos;
- Application formats like .exe and .dmg → Dapps on different blockchains;
- Word document → On-chain assets;
- Crossover → Cross-chain bridges;
- Virtual Machine (VM) → Low-compatibility EVM implementations; e.g., Polygon Hermez is a ZK VM that mimics EVM functions and requires manual updates to maintain parity;
- JVM → EVM; language-level equivalent compatibility; e.g., Scroll’s planned ZK-EVM is fully equivalent to EVM—essentially an EVM with integrated ZK features;
- Binary compatibility → Native EVM or Ethereum itself;
As described above, the characteristics of VMs and EVMs closely mirror the process of transferring files across operating systems. In R3PO’s view, the dominant trend will be that ZK-EVM not only replaces existing EVM-compatible solutions but ultimately establishes Ethereum as the sole application-layer communication protocol. Other blockchains will become specialized chains serving niche domains—similar to how Linux dominates server environments while Windows prevails among general users.
Below, we elaborate on the reasoning behind this conclusion.
To Understand Others, One Must First Understand Oneself:The Essence of an Ecosystem Is a Mutual Pursuit Between Developers and Users
EVM contributed significantly to Ethereum’s victory in the public chain competition—not due to superior computational performance, but mainly because of compatibility. Competitors like EOS (an earlier "Ethereum killer"), Solana (a previous-generation contender), and Aptos (a newer challenger) all boasted ultra-high TPS speeds.
Yet Ethereum remains unshaken, maintaining absolute dominance in TVL and number of Dapps despite single-digit TPS. This advantage stems from network effects—but why hasn’t the gap narrowed, even as other chains adopt EVM compatibility and build extensive cross-chain bridges? Why does the disparity appear to widen further during bear markets?
R3PO suggests starting from a clear foundational point to find the answer.
That starting point is developer experience. Web3 today remains in its earliest stages—comparable to the internet before 2000—still dominated by tech enthusiasts and early adopters. Despite token incentives, most users remain within CEXs and CeDeFi structures built by TradFi institutions. True on-chain users are scarce: Ethereum has only about 400,000 active addresses, yet its TVL exceeds $32 billion and market cap surpasses $200 billion.
Given this stark contrast between user numbers and capital depth, attracting developers becomes the key to sustaining an ecosystem. The logic is simple: whichever chain persists until the emergence of truly billion-user applications will become the foundational infrastructure of the next-generation internet—much like the World Wide Web and Netscape Browser defined the early internet era.
And Ethereum offers developers the most complete development experience.
In a sense, this mirrors Java’s success. Before Java, C/C++ required programmers to manage software-hardware compatibility—for example, 32-bit data types couldn’t directly run on 16-bit machines.

Image description: JVM architecture
Source: Wikipedia
Java improved usability, but its greatest innovation was the JVM design. In short, it achieved “hardware softening”—using language abstraction to uniformly adapt to diverse hardware. Once compiled for the JVM, code can run anywhere. This enables true cross-platform development without worrying about underlying hardware differences.
Thanks to the JVM, Java became one of the world’s most widely used programming languages—not necessarily best-in-class for any single domain, but applicable across all. This is the essence of compatibility.
Ethereum and its EVM-based development ecosystem work similarly. Developers need only target EVM once, then benefit continuously from Ethereum’s evolving ecosystem—without needing to worry about blockchain upgrades, hardware differences, or compatibility issues.

Image description: EVM architecture
Source: ethereum.org
Solidity isn’t perfect, and EVM has flaws—but its superior compatibility ensures developer loyalty. As more chains adopt EVM compatibility, this standard gains passive momentum. Migration costs between chains are minimal, making alternative chains little more than localized versions of Ethereum Dapps. Ultimately, this reinforces Ethereum’s ecological dominance.

Image description: EVM workflow illustration
Source: R3PO
Moreover, language-level compatibility helps ensure EVM efficiency and security.
The virtual machine (VM) mentioned above refers to inter-operating system emulation tools like Parallels Desktop, which allows running a Windows subsystem on Mac. This requires allocating dedicated system resources first, installing Windows apps within the subsystem, and then executing them. However, due to resource constraints, performance lags far behind native applications.
In contrast, EVM operates more like JVM—at the language level. Developers use Infura APIs to interact with the mainnet, Truffle for smart contract development, testing, and deployment. The tooling suite is comprehensive. Once adapted to EVM, Dapps can run seamlessly across any EVM-compatible chain.
This consistency benefits not just developers—it ensures a uniform user experience regardless of chain. This preserves Ethereum’s core seed user base. With just developers and a small cohort of users, Ethereum maintains a decisive edge over competing ecosystems.
EVM takes inspiration from JVM—abstracting away hardware and encoding complexities so developers can focus solely on functional needs. Develop once, deploy everywhere.
An ecosystem means developers + applications + users. EVM kickstarted the flywheel effect in ecosystem building.
To Judge Others, One Must First Judge Oneself:EVM Compatibility Does Not Empower Challengers to Win
EVM fueled Ethereum’s success—but why haven’t other EVM-compatible chains, including so-called "vampire projects" siphoning Ethereum’s ecosystem, succeeded?
**The challengers’ logic:**
- To developers: Offer EVM compatibility to reduce migration costs, plus enhanced features like higher TPS;
- To users: Provide token incentives to encourage migration;
- Goal: Replace Ethereum.
**Flaws in their logic:**
- For developers: EVM compatibility ≠ native EVM—hidden migration costs still exist;
- For users: Ethereum offers the highest security after Bitcoin, something short-term rewards like farming or airdrops cannot match;
- Result: Ethereum retains its dominant position.
In reality, competing chains face a dilemma: embracing EVM risks becoming de facto sidechains of Ethereum, while rejecting it leads to isolation. Amid universal demand for traffic, EVM compatibility becomes a reluctant compromise.

Image description: Overview of EVM compatibility approaches
Source: R3PO
Currently, other chains are taking proactive steps, while Ethereum focuses on resolving legacy issues—PoW to PoS transition, L2 roadmap decisions, account abstraction, Danksharding, etc. In terms of compatibility paths, three main strategies exist: implementing EVM natively, achieving cross-chain compatibility through applications, and building EVM-compatible chains.
Native EVM Implementation – Represented by BNB Chain.
Exchange-led blockchains like BNB Chain and OKX Chain leverage their large user bases and strong project operational capabilities. Their TVL and ecosystems are significant. For instance, according to DeFi Llama, BNB Chain hosts 492 protocols with a TVL of $6 billion—making it the second-largest public chain after Ethereum in scale.
Their primary model is to mimic Ethereum. PancakeSwap, BNB Chain’s largest DEX, originated as a fork of Uniswap. The same Dapp can switch seamlessly between chains—thanks to EVM compatibility. Projects can thus focus on operations rather than rebuilding products from scratch.
On-Chain EVM Compatibility – Represented by Solana.
Solana is a PoH-based monolithic blockchain and was long the only top-ten market cap chain not natively EVM-compatible. Yet it can still interoperate with EVM chains—via Neon, a project running on Solana that provides EVM compatibility.
This can be seen as a "matryoshka doll" approach—compatibility layered atop the chain rather than implemented at the base layer.
Neon delivers a development experience highly similar to native EVM: Solidity support, seamless smart contract deployment, direct integration with MetaMask and Truffle.
Dedicated EVM-Compatible Chains – Represented by Evmos.
Modular blockchains like Cosmos or Polkadot offer more flexibility—applications can become standalone L1 chains. Evmos is both a Cosmos zone and an EVM-compatible chain. This means Evmos can propagate EVM compatibility not just within Cosmos, but potentially across any blockchain ecosystem.
Beyond providing EVM compatibility, Evmos also serves as a standalone chain hosting DeFi applications—Exswap, its native DEX, is a fork of Uniswap.
**Summary:** This broad compatibility has enabled connectivity across the blockchain space, with EVM compatibility, cross-chain bridges, and exchanges acting as key enablers. Based on this, R3PO outlines the major compatibility paradigms—to set the stage for ZK-EVM’s potential role as a game-changer.
To Defeat Others, One Must First Overcome Oneself:ZK-EVM Is Ethereum's Counteroffensive
While other chains scrambled to achieve EVM compatibility, Ethereum focused inward. But after successfully completing the PoS merge and finalizing its L2 strategy, ZK technology has emerged as a universal primitive across the blockchain landscape. The convergence of ZK and EVM will complete Ethereum’s modular architectural evolution.
ZK is not limited to L2—it has applications across layers, from Dapps to base protocols. Yet the booming ZK-EVM space is somewhat chaotic. R3PO aims to clarify and distill the signal from the noise.

Image description: Trade-offs between EVM compatibility and performance
Source: vitalik.eth
Vitalik once illustrated the relationship between EVM compatibility levels and performance: the lower the implementation layer, the stronger the compatibility but the worse the performance. This is intuitive—compare Ethereum’s weak performance with its unmatched security.
- The **closer to the base layer**, the more closely it mirrors native EVM behavior—higher compatibility, but severe performance limitations;
- The **higher up the stack**, the more it depends on custom EVM-compatible designs—greater deviation from native EVM, weaker compatibility, but greater freedom for optimization and performance gains.
Earlier, we mentioned Polygon Hermez, categorizing it under ZK VMs. Although Hermez calls itself a ZK-EVM solution, this one-letter difference masks vastly different implications for compatibility and security.
Polygon Hermez essentially replicates EVM functionality one-to-one—like WBTC to BTC, or a shadow to its object. During normal operation, if the team keeps it updated, the user experience matches EVM. But it is not implemented at the language level—this is marketing spin in competitive positioning.
Recently, StarkNet launched Kakarot, a ZK-EVM written in Cairo, enabling Ethereum smart contracts to run on StarkNet. This marks the first ZK-EVM entering testing. Others in the pipeline include Taiko, Scroll, zkSync 2.0, and more.
Why has ZK-EVM become such a hot field? And why might it be the ultimate disruptor?
Commercial messaging remains incomplete at this stage. R3PO offers its interpretation—not as definitive truth, but to spark discussion.

Image description: Ethereum architecture in the ZK-EVM era
Source: R3PO
**For the first question: ZK-EVM is where future Dapps will truly reside.**
Conventionally, Dapps run either on L1s or L2s. But R3PO believes ZK-EVM will directly host the application layer.
As shown above, future ZK-EVMs will integrate EVM, Rollup, and cross-chain bridge functionalities. That it is an EVM needs no explanation—let us focus on the latter two.
L2 Rollups are too low-level. To achieve higher performance, take StarkNet as an example: it plans to use recursive ZK proofs to verify data validity. Recursion allows infinite scalability (“proving the past with the future”), while ZK ensures data size remains bounded. Thus, StarkNet can serve as a validation layer for applications or even L3s built atop it.
Cross-chain bridges are easier to grasp—their purpose is asset exchange across chains. If all chains share EVM compatibility, bridges become unnecessary intermediaries. Compared to today’s frequently exploited bridge designs, ZK-based solutions are inherently more secure. Hence, ZK-EVM represents a superior cross-chain mechanism.
**For the second question: ZK-EVM will turn every public chain into an EVM chain.**
Even non-EVM-native chains like Solana and Aptos can integrate via Evmos. From this perspective, ZK-EVM is Ethereum’s offensive move: even if you don’t connect to me, I’ll connect to you. This further amplifies Ethereum’s ecosystem advantage.
As for Move-based chains like Aptos and Sui, their Move VM resembles EVM in development model. Theoretically, Move—a Rust-derived language—is superior to Solidity. But its fatal flaw is timing. Whether it can generate sufficient organic traffic and ecosystem growth is questionable—and it faces the same EVM-compatibility dilemma as other chains.
Conclusion
A public chain’s market success depends not only on effort, but also on historical momentum.
In the evolution of ZK-EVM, we clearly sense the intense struggle behind the scenes. The tug-of-war between Ethereum and competing chains has generated endless narratives. Now, the decisive moment has arrived—a life-or-death clash between emerging paradigms like Evmos, Move VM, and ZK-EVM.
R3PO believes the future blockchain landscape must be based on interoperability driven by EVM compatibility. Users and developers remain the heart of the story.
If ZK-EVM progresses smoothly, Ethereum could become the “Windows” of the blockchain world—hosting the richest application layer and serving as the most secure and stable settlement layer.
ZK technology still needs at least five years to mature broadly. With massive capital and market acceleration, this timeline may shorten to around three years. Then, we will see whether today’s predictions come true.