The Dawn of zkEVMs
The blockchain trilemma states that the three pillars of a public blockchain – security, scalability and decentralization – are at constant odds and only two of the three pillars can be maximized. The most common trade-off made in the trilemma is to sacrifice a level of decentralization to improve scalability.
To solve the trilemma and improve scalability without sacrificing decentralization, many teams are working on Layer 2 (L2) solutions, in particular, optimistic rollups and zero knowledge rollups (zk-rollups). In the zk-rollup space, there has been a race to produce what is known as a zkEVM.
We highlight what zk-rollups and zkEVMs are and the development that’s currently happening in its space.
Zero Knowledge SNARKs and STARKs
Zk-rollups are essentially L2 blockchain scaling solutions that facilitate both off-chain and on-chain operations. With zk-rollups, instead of transactions being processed on Ethereum directly, -large amounts of transactions are processed off-chain and compressed. The results of the bulk transactions are then submitted back to Ethereum for recording as one transaction along with a cryptographic validity proof. Smart contracts are used to maintain accurate state change during the submission process. This differs from optimistic rollups where condensed transactions are submitted to Ethereum without proof but there is a window time (usually 7-days) where a fraud proof can be submitted to challenge the results.
When a rollup batches transactions, it has to prove the validity of each transaction to the on-chain contract on Ethereum. It proves this in a way such that the content of the transactions aren’t revealed or done on the chain. These validity proofs come in two types: zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) or zk-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge).
zk-SNARKs employ the use of a Common Reference String (CRS) in a trusted setup. Hostile perpetrators can generate false validity proof if they somehow get the transaction’s CRS.
zk-STARKs do not require a trusted setup and do not need the Common Reference String to generate a validity proof and secure the transaction’s data. In addition, Zk-STARKs offers more scalability as the time taken to give validity proofs is quasi-linearly proportional to the complexity of the cryptographic computation. This means it takes less time to validate transactions using zk-STARKs than zk-SNARKs.
Protocols using zk-SNARKs include Loopring, Polygon Hermez, ZKSync, and ZKSwap while Starkware/StarkEx, Immutable X, DyDx, StarkNet, Polygon Miden are based on zk-STARKs.
The Need For zkEVM
While zk-rollups offer an exciting opportunity to scale Ethereum, to-date, not much activity has migrated from L1 to zk-rollup L2’s outside of application specific zk-rollups like DYDX and Immutable X. StarkWare’s general purpose StarkNet, where dApps are developed in its own specialized language called Cairo, has had low adoption to date.
Just as alt-L1’s were able to bootstrap adoption quickly by leveraging the familiar EVM, the idea is that zk-rollups could do the same through zkEVM.
The Different Flavors of zkEVMs
Simply put, zkEVM will soon make zkrollups perform like Ethereum in various capacities (Ethereum equivalence), but with even more scalability. However, when we consider their equivalence with Ethereum layer 1, according to Vitalik Buterin, we have different types of zkEVMs:
Source: Vitalik Buterin
In essence, EVM-equivalence can be viewed as a continuum. On one end of the spectrum, there is the fully Ethereum-equivalent zkEVM, which Vitalik terms Type 1. This is like a perfect replica of the Ethereum blockchain. However, because Ethereum was not originally designed to be zk-proof friendly, many parts of Ethereum require intensive computation to generate zk-proofs without altering Ethereum. As a result, Type 1 zkEVMs have very high proving times. As we move along the EVM-equivalence continuum, more changes are made to Ethereum’s design to optimize proving times. Vitalik’s blog post on the topic is well worth reading.
Most zkEVM projects want to achieve closer and closer EVM-equivalence over time, but as of now, Vitalik considers Scroll and Polygon’s zkEVM Type 3, and zkSync as Type 4.
Type 3: Almost EVM-Equivalent zkEVMs
Type 3 zkEVMs are almost equivalent but removes certain features of Ethereum, such as certain precompiles to improve proof times. Most existing Ethereum applications will work but some applications will need to be rewritten due to precompiles and edge cases.
Type 4: High-Level-Language Equivalent zkEVM
Type 4 zkEVMs compile smart contract code written in a high-level language (solidity, Vyper) into another language that is zk-proof-friendly. This boosts prover time exponentially. However, it comes with some shortcomings mostly related to compatibility: existing debugging infrastructures can’t be carried over, complicated use of handwritten bytecodes; contracts won’t have the same address.
Various zkEVM Implementations
Polygon zkEVM is currently in the testnet stage, and they expect to launch mainnet beta on March 27th.
Polygon zkEVM is the culmination of work that started with Hermez nearly two years ago. Polygon acquired Hermez in August 2021 and work on a zkEVM has continued ever since.
According to Polygon, the main features of their zkEVM are:
- Ethereum-equivalence: all smart contracts, wallets, tools, etc work on zkEVM seamlessly.
- Ethereum security
- ZKP-powered scalability, orders of magnitude higher throughput than L1.
Polygon has open sourced their zkEVM code base, including its prover. As mentioned above, Vitalik Buterin classified Polygon zkEVM as “Type 3: Almost EVM-equivalent”. Gas fees on Polygon zkEVM will be paid in ETH while MATIC will be used for staking and governance.
Matter Labs built zkSync, a zk-rollup, and is currently working on zkSync Era (formerly known as zkSync 2.0), a zkEVM enhanced version of zkSync. As mentioned above, Vitalik classified zkSync Era as “Type 4: High Level Language Equivalent zkEVM”.
The upcoming zkSync Era will allow its users to choose between two modes – zk-rollup mode or zkPorter mode. The choice has to do with where data required to recreate roll-up transactions will be stored (data availability). The data needs to be made “available” to anyone who is interested in recreating and verifying the rolled up transactions. In zk-rollup mode, the transaction data is stored directly onto Ethereum. This is the most secure option but also more expensive. In the zkPorter option, transaction data is stored on a sidechain secured by zkSync validator stake. This is less secure than Ethereum, but unlocks an additional gain in scalability.
zkSync Era is currently in mainnet alpha for projects who have signed up to launch on Era. Mainnet Beta is expected to follow but a launch date has not been released.
Scroll is another project working on a zkEVM to bring EVM compatibility to a zk-rollup. Scroll has been working on this for about 2 years and just announced their alpha testnet on Goerli having been in pre-alpha stage since August 2022. This is the last stage before mainnet. Since August 2022, the pre-alpha testnet has processed over 15,400,000 transactions and proved 1,800,000 blocks. Vitalik has considered Scroll’s zkEVM implementation as a Type 3 zkEVM.
The rollout of the zkEVM is coming this year, making it a big year for Ethereum and the teams working on zkEVM.
Zk-rollups have the promise to be a groundbreaking advancement in blockchain scalability. Bringing a familiar virtual machine like the EVM to Zk-rollups could help increase developer and user adoption and move transaction activity from L1 to L2.
This article has been written and prepared by Makinde Adeniyi – a member of the GCR Research Team, a group of dedicated professionals with extensive knowledge and expertise in their field. Committed to staying current with industry developments and providing accurate and valuable information, GlobalCoinResearch.com is a trusted source for insightful news, research, and analysis.
Disclaimer: Investing carries with it inherent risks, including but not limited to technical, operational and human errors, as well as platform failures. The content provided is purely for educational purposes and should not be considered as financial advice. The authors of this content are not professional or licensed financial advisors and the views expressed are their own and do not represent the opinions of any organization they may be affiliated with.