Table of Contents
Researcher
Key Takeaways
ZKsync has established a foundation to accelerate ecosystem expansion by overcoming the limitations of the previous EraVM through its update that achieves full EVM compatibility.
Additionally, by announcing their own Solidity compiler, solx, they've secured a technical advantage that offers gas cost reduction and compatibility with various virtual machines, allowing them to quickly respond to the possibility of a RISC-V transition.
These two updates demonstrate that ZKsync is going beyond being just a rollup to build an Elastic Chain ecosystem based on the ZK Stack, showing the potential to form a competitive structure with the Optimism Superchain ecosystem.
1. Background - Recent Updates to ZKsync and Their Significance
1.1. Achieving Full EVM Equivalence
Most zero-knowledge rollups modify EVM or develop their own VM for efficiency. In the computational process of Zero-Knowledge (hereinafter ZK) based protocols, proof generation is the biggest bottleneck, and performing it directly on the native EVM is computationally intensive. EVM which has been modified or enhanced for zero-knowledge computations is called zkEVM.
zkEVMs are categorized into Type 1~4 based on their compatibility with the native EVM, with ZKsync Era previously falling into type 4, the lowest level of EVM compatibility. This is because ZKsync uses its own ZK-optimized virtual machine called EraVM, which is LLVM-based. Solidity/Vyper code would be compiled using their proprietary compilers, zksolc/zkvyper, and EraVM would execute the bytecode generated through this process.
Source: Ethereum Daily
However, this structure has caused various inconveniences, which can be summarized as follows:
Low compatibility with EVM development tools: Various development tools based on computational simulation couldn't provide full compatibility with EraVM. To use the most common development tools in the EVM ecosystem like Foundry and Hardhat, developers had to use additional plugins developed by Matter Labs such as foundry-zksync and hardhat-zksync. Having to learn additional commands for these tools and the limitations on using various useful debugging tools could be a significant inconvenience for developers.
Low-level compatibility issues: The differences between EraVM and EVM are particularly prominent in low-level development, with the CREATE2 opcode compatibility issue being the most representative example. CREATE2 is an opcode that creates addresses, allowing developers to predict the address of a contract before deployment, which is very useful for account abstraction and other applications. However, since the addresses generated depend on bytecode hashes, and EraVM doesn't fully support CREATE2 due to differences in hashing methods. This caused additional overhead for existing account abstraction projects deploying contracts on ZKsync, which ZKSync addressed by implementing its own AA at the network level. Additionally, other issues such as limited address ranges and various bytecode restrictions have been inconvenient during development and testing.
Security issues: Though mostly resolved recently, ZKsync had instruction-level differences from EVM, which could lead to critical problems like fund loss if not properly considered during development. A notable example is the Gemholic incident, where they implemented a pre-funding contract without realizing that zkSync didn't support the .transfer() method, resulting in the freezing of about 921 ETH of user funds. Such contracts developed without awareness of EVM compatibility differences can cause serious issues, leading to implementation modifications and additional audit costs, creating obstacles for projects deployed on fully EVM-compatible chains to onboard onto ZKsync.
Source: ZKsync
However, ZKsync announced the achievement of full EVM equivalence, completely resolving these issues. So what updates have been made to ZKsync for this?
Through the recent update, ZKsync added an EVM interpreter within EraVM. The EVM interpreter first runs EVM bytecode compiled with solc/vyper internally and then converts it into opcodes that EraVM can execute. Simply put, they've built the plugins previously required for contract development directly into the virtual machine. In addition to the interpreter, they've implemented CREATE2, ERC-2470 singleton factory, Multicall3, and all other elements that were previously incompatible with EVM as precompiled contracts, eliminating all developmental differences from EVM.
Source: ZKsync Developers
While the diagram makes the structure look simple, the impact for developers is substantial. This update integrates ZKsync’s development environment with other EVM chains. Projects that previously hesitated to use ZKsync can now deploy contracts without additional overhead. This integration will likely become a significant advantage for the entire ecosystem.
1.2. A New Solidity Compiler: solx
Following this, on the 9th, ZKsync announced their in-house developed Solidity compiler, solx. Currently, Solidity has no compiler options other than solc, and while solx is not yet complete, the addition of another compiler option has significant implications for the development ecosystem.
When a programming language only supports a single compiler, various problems of a monopolistic ecosystem can arise. A representative issue is that if a compiler bug occurs, all programs based on that language could be affected. The web3 ecosystem has experienced a major incident due to the compiler bug; in 2023, a bug in the Vyper compiler handling reentrancy resulted in the theft of over $50 million from Curve Finance pools.
Additionally, there are various limitations such as restricted optimization techniques and architecture compatibility. Implementing an additional compiler and open-sourcing it is a tremendous contribution to the EVM development ecosystem.
solx is built on the open-source compiler LLVM, which is one of the longest-developed compilers with excellent compatibility with various architectures. solx extracts information from code written in Solidity via solc, converts it into an intermediate representation that LLVM can read, and then transforms it into bytecode after additional optimization.
Source: ZKsync Blog
So what advantages does solx offer?
The most notable strength is gas cost reduction through LLVM optimization. According to Matter Labs' benchmarks, solx achieves approximately a 10-40% gas cost reduction in runtime environments compared to bytecode compiled with solc. solx includes various software optimization techniques such as loop unrolling that previously had to be done manually, which can reduce development costs aimed at optimizing gas fees in addition to enhancing on-chain usability.
Source: ZKsync Blog
solx is still in the alpha stage and doesn't yet have complete compatibility with all contracts. Experiments with major contracts in Ethereum show an 80-100% compilation success rate, with most of the issues being the chronic solc problem of "stack-too-deep" errors, which they are actively working to resolve.
The second strength is strong virtual machine environment compatibility. Designed based on LLVM, solx provides the flexibility to easily expand to new virtual machines beyond EVM. solx was designed with the possibility that Ethereum might transition to a RISC-V based virtual machine, which aligns with Vitalik's proposal from April to replace EVM with RISC-V. Beyond the scenario of Ethereum adopting RISC-V, this also means various alternative VMs (altVMs) can quickly adopt Solidity as their implementation language.
2. Takeaway - ZKsync Is More Than Just a Rollup
Source: Delphi Digital
Chains implemented based on the ZK Stack, such as Abstract, Lens, and Sophon, are continuously emerging. Similar to how chains developed with the Optimism Stack are trying to form a superchain ecosystem centered around Optimism, ZKsync has a vision to connect these under the name "Elastic Chain."
It's noteworthy that optimistic rollups developed with the Optimism Stack, such as Boundless and Succinct, are attempting to transition to zero-knowledge (or hybrid) rollups through integration with prover networks. Most notably, Mantle and Chroma have announced their transitions to zero-knowledge and hybrid rollups, respectively, through Succinct.
Considering the gradual reduction in zero-knowledge proof generation costs and the advantages of improved usability and decentralization through transitioning to zero-knowledge rollups, I expect more optimistic rollups to transition to zero-knowledge rollups. This will create a competitive structure between the {Optimism Stack + Prover Network} ecosystem and the ZK Stack ecosystem.
Until now, the expansion of the ZK Stack has been limited by the strong barrier of lacking EVM compatibility, making meaningful comparison impossible. However, with this compatibility update, the zero-knowledge infrastructure ecosystem can enter a more full-fledged cost/performance competition. The {Optimism Stack + Prover Network} configuration can be likened to modular, while the ZK Stack can be compared to monolithic. It will be interesting to see if the ZKsync ecosystem, with Matter Labs' unique research capabilities, can gain an advantage over the prover network-based ecosystem.
solx is also clear evidence of the ZKsync team's technical superiority. Designing a compiler that is more efficient and bug-free than existing ones is a very challenging task, which is why Solidity has had no compiler options other than solc for the past decade. At a time when radical changes like transitioning the execution environment to RISC-V are being discussed in the Ethereum ecosystem, ZKsync's technical superiority can be a very important competitive factor. The flexible architecture of solx can quickly adapt not only to EVM but also to new virtual machines like RISC-V, suggesting that the ZKsync team has the capability to respond more swiftly than anyone else to changes in the Ethereum ecosystem.
