Sophon Achieves EVM Equivalence And Introduces Enhanced Developer Features

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.Post for builders: As of last night (UTC), @sophon inherited the amazing work by @the_matter_labs for @zksync and became EVM equivalent.If you don't want to leverage the additional great features from our EraVM, you can just deploy regular EVM contracts with regular EVM...— 0xRamon.eth (+) (@ramonIsTweeting) May 13, 2025Key Features Of Virtual Machine Bytecode InterpreterZero-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.The post Sophon Achieves EVM Equivalence And Introduces Enhanced Developer Features appeared first on Metaverse Post.