rewrite this title Sophon Achieves EVM Equivalence And Introduces Enhanced Developer Features

by
Alisa Davidson

Published: May 13, 2025 at 9:09 am Updated: May 13, 2025 at 9:09 am

by Ana

Edited and fact-checked:
May 13, 2025 at 9:09 am

To improve your local-language experience, sometimes we employ an auto-translation plugin. Please note auto-translation may not be accurate, so read original article for precise information.

Entertainment-focused blockchain platform Sophon announced the adoption of core technology developed by Matter Labs for the Ethereum Layer 2 rollup ZKsync. As a result, the platform has achieved Ethereum Virtual Machine (EVM) equivalence.

EVM equivalence refers to the extent to which another blockchain environment can replicate Ethereum’s Virtual Machine behavior exactly, including compatibility at the bytecode level.

Sophon noted that developers who choose not to utilize additional features from its custom EraVM can still deploy standard EVM smart contracts using conventional Ethereum development tools. This enhancement is expected to simplify development and support the creation of more practical applications for end users.

Key Features Of Virtual Machine Bytecode Interpreter

Zero-knowledge (ZK) chains such as Era utilize EraVM, a virtual machine designed specifically for ZK applications, which differs from the EVM in terms of its instruction set and execution model. While smart contracts written in Solidity or Vyper can be compiled for EraVM, certain execution differences and tooling limitations have historically required some adaptations.

In order to mitigate these challenges, ZKsync has implemented an EVM execution mode using an EVM Bytecode Interpreter. This allows unmodified EVM bytecode to be executed on ZK chains without the need for recompilation or changes to development tools. This compatibility makes it possible for applications originally built for Ethereum to run on ZKsync while EraVM continues to serve as the underlying execution engine.

The EVM Interpreter does not replace EraVM; rather, it functions as a compatibility layer that enables Ethereum-based bytecode to operate within the EraVM infrastructure. When an EVM contract is deployed, its bytecode hash is tagged with a specific identifier that signals the system to execute it via the interpreter rather than natively through EraVM.

During execution, EVM opcodes are processed at runtime by the interpreter, which maps them to their corresponding EraVM instructions while aiming to replicate Ethereum’s behavior as closely as possible. In terms of resource usage, while the execution is priced using EraVM’s native gas unit, the EVM gas model is maintained within the interpreter for internal accounting.

Solidity and Vyper contracts can be deployed directly without the need for recompilation using tools like zksolc or zkvyper, maintaining compatibility with the original Ethereum bytecode. This enables straightforward migration or parallel deployment of existing smart contracts. The system also supports standard Ethereum development environments, allowing developers to use frameworks such as Foundry, Hardhat, and Remix without requiring any custom plugins or additional configuration. This helps preserve familiar workflows and simplifies integration.

Address derivation behaves consistently with Ethereum’s specifications, meaning that the create and create2 operations produce identical contract addresses as they would on the Ethereum mainnet, ensuring predictability and compatibility. In addition, several system-level contracts are pre-deployed and ready for immediate use, including implementations like create2, multicall3, and singletonFactory (aligned with ERC-2470). This pre-availability streamlines development by reducing setup requirements and providing ready-to-use infrastructure components.

Although the interpreter enables contracts written for Ethereum to run without modification, there are notable distinctions between this setup and running contracts on the Ethereum network directly. 

For example, gas fees are paid in ergs—EraVM’s native unit—not in Ethereum’s gas. Some EVM operations, such as CALLCODE and SELFDESTRUCT, are not supported due to technical constraints in EraVM. Additionally, the translation process results in higher transaction costs, often ranging from 1.5 to 4 times more than those incurred by native EraVM contracts.

Cross-compatibility is also limited, with functions like `delegatecall` not working between EVM and EraVM contracts. Therefore, while the EVM Interpreter offers convenience for teams seeking Ethereum compatibility, contracts written specifically for EraVM are generally more cost-efficient and performant. Developers are advised to use native EraVM deployment when optimal execution efficiency is a priority.

About The Author

Alisa, a dedicated journalist at the MPost, specializes in cryptocurrency, zero-knowledge proofs, investments, and the expansive realm of Web3. With a keen eye for emerging trends and technologies, she delivers comprehensive coverage to inform and engage readers in the ever-evolving landscape of digital finance.

More articles

Alisa Davidson

Alisa, a dedicated journalist at the MPost, specializes in cryptocurrency, zero-knowledge proofs, investments, and the expansive realm of Web3. With a keen eye for emerging trends and technologies, she delivers comprehensive coverage to inform and engage readers in the ever-evolving landscape of digital finance.

More articles