EraVM or EVM? A Tale of Two VMs

Red Light, Green Light?

Through all the amazing innovations and catalysts that ZKcandy brings to the table, there has been one glaring weakness that often frustrates developers who want to bring their exciting experiences to the supercharged world of ZKcandy - and that’s the tooling that needs to be relearned when deploying to ZKcandy.

While the tooling for ZKcandy deployment is a minute change for most web3 developers, more experienced developers may find it frustrating as it can involve changes in deployment scripting especially in larger projects.

ZKcandy is on the cusp of becoming EVM equivalent. In this article, we will address the benefits of waiting for this functionality on ZKcandy against the unique strengths of deploying to the existing EraVM.

Out With The Old?

Let’s establish first and foremost that when the page turns and ZKcandy becomes EVM equivalent, it does not mean that EraVM will be deprecated. EraVM will still be the bedrock of ZKcandy, as it is with other Elastic Chains and chains built on the ZK stack. Therefore the question about the relevance of the EraVM will still be something to consider when mulling how to deploy your project to ZKcandy.

Candy-coated EVM

EVM equivalence on ZKcandy may come with a misconception that EVM will become ZKcandy-native when in actual fact, what happens behind the scenes is that EVM opcodes must be transpiled into EraVM proofs first so that they can be executed on ZKcandy. The additional compute required for this does increase the gas usage when interacting with EVM contracts on ZKcandy.

The tl;dr version of this article comes down to transaction fees for deploying and using contracts, otherwise known as gas.

As with most Layer-2 blockchains, ZKcandy has low gas fees on the network thanks to Gas Fee Rebates - a mechanism unique to the ZK Stack upon which ZKcandy is based on. With this knowledge, one might assume that the difference and/or savings in gas costs are negligible. However, gas fees add up over time. Even small savings can make big differences for large projects and builders who are here for the long run.

Of course, lower gas fees for your users is often a great way to sweeten the deal and attract them to your dApp!

What you’re paying for

ZKcandy charges fees based on both computation and proving (not just "gas" like Ethereum). EraVM-optimized code uses fewer constraints (the math that goes into ZK proofs), so the prover does not have to work as hard to process your transaction.

Take for example - a for loop running in the EVM equivalence layer may cost up to five times more than a refactored loop that uses batch processing off-chain or fixed-size arrays running in EraVM. This is because EraVM’s compiler (zksolc) and ZK-prover (Boojum) reward code that plays well with ZK-proof-friendly patterns (e.g., fixed-size logic over dynamic loops).

So what works better on EraVM? Here are some examples:

Specific signature verification algorithms
Privacy-preserving mechanics (e.g., on-chain encryption, zero-knowledge checks)
High-throughput systems (e.g., games, voting platforms)

Of course, this doesn’t mean that any signature verification algorithm will be more efficient on the EraVM - you can instead look towards optimising your contract to use more suitable ZK-friendly hash algorithms such as EraVM’s Poseidon hash to reduce compute costs significantly.

ZK proofs translate code into arithmetic constraints. Some opcodes (like ecrecover or sha256) are “expensive” for ZK to prove. EraVM doesn’t automagically make these problems vanish, however. If you are interested in making your contract more optimised for compute, feel free to take a deep dive into EraVM and the Boojum prover and explore further.

EraVM’s Superpowers

So far this article sounds like EraVM is not worth the extra time and effort to work with and that EVM equivalence is far more applicable throughout the world of web3. That’s why it’s not out of place for you to ask, why bother with EraVM?

EraVM isn’t just an EVM compatibility VM. It’s also a gateway to ZK-specific capabilities like:

On-chain data compression
Recoverable signing without ecrecover
Custom precompiles for cryptographic primitives

One of the significant advantages of the way that EraVM works is that instead of storing raw data on-chain (which costs L2 gas for calldata), EraVM allows you to store only proofs of data, compressing the size and reducing fees.

ZKcandy also benefits greatly from ZKsync’s Native Account Abstraction through EraVM’s ability to accept signature algorithms other than ecrecover, including off-chain signature verification with on-chain proofs!

The Caveats

Most web3 developers who explore ZKcandy would most likely be already familiar with the EVM and the way it works. On ZKcandy, the EraVM faithfully replicates the EVM execution environment for what’s most probably 99% of Ethereum use cases.

Most of you reading this wouldn’t need to be too bothered with the 1% - but we will briefly touch on it here.

ZKcandy will achieve EVM compatibility by translating Ethereum-like execution into ZK-provable logic using a ZK-EVM compatibility layer. This layer sits within the EraVM, which is a modified virtual machine that mimics the Ethereum state transition function but structures its computations in a way that aligns with zero-knowledge proof systems (like PLONK).

Operations such as ecrecover(...) and dynamic for loops will result in higher gas fees on EraVM. While ecrecover(...) is a precompile on EVM, it is slow on EraVM as it uses a ZK-circuit for Ethereum signatures. Dynamic for loops, which scale with the number of iterations on EVM, are very expensive on EraVM because EraVM proves all possible loop lengths, inflating constraints.

EraVM doesn’t make "bad" ZK operations disappear. It just handles them in a way that feels like the EVM while still respecting ZK proving constraints. Here’s how this plays out:

Operation	EVM	EraVM	Why It Seems “Smooth”
`keccak256("hello")`	Efficient	Still okay	Used often in Ethereum; EraVM optimizes via batching.
`ecrecover(...)`	Precompile	Slow	EraVM uses a ZK-circuit for Ethereum signatures; developers don’t notice this.
Dynamic `for` loops	Scales with # of iterations	Very expensive	EraVM proves all possible loop lengths, inflating constraints.
Storage writes	Costly	Costly	EraVM still needs Merkle proofs for L2-to-L1 state verifiability.

It’s useful to also know that ZKcandy handles the proving inefficiencies on the backend through transaction batching and Prover-side tuning - therefore compute and gas costs are not deterministic to single transactions but also to batches of transactions.

So unless you’re building something complex that uses lots of computational logic - you should be fine with using ZKcandy’s EVM equivalence.

Why wait?

ZKcandy is already ready today - and it’s going to get better. Deploying to EraVM may sound intimidating but thanks to the new and improved ZKsync plugin for the Remix smart contract IDE, this is now easier than ever.

Check out our previous article and take the plugin for a spin today!