ZK-EVMs — Scaling the Ethereum Blockchain
The Merge has been completed, and the Ethereum blockchain community is focusing on how to begin scaling the blockchain to allow for cheaper transaction fees, faster transactions, and more throughput while maintaining the security of decentralized finance (DeFi) protocols and other Decentralized Apps (dAPPs) built on the blockchain. Zero Knowledge Ethereum Virtual Machines (zk-EVMs) currently constitute one of the most critically acclaimed scaling techniques developed within the Ethereum community.
Today’s newsletter will examine zk-EVMs and some key projects to note in the zk-EVM sphere. To understand what zk-EVMs are, we first need to understand two key concepts; Zero-Knowledge Rollups (zk-Rollups) and Ethereum Virtual Machines (EVM)
What are ZK-Rollups
A ZK-Rollup is a Layer-2 scaling solution that operates on top of the Ethereum blockchain. ZK-Rollups are off-chain protocols that execute transactions outside the Ethereum blockchain and then commit the transaction batches back on-chain via an on-chain rollup contract. A ZK-rollup processes transactions, performs computations, and stores data off-chain while holding assets in an on-chain smart contract.
Essentially, zk-Rollups process a transaction off-chain to reduce the demand for block space while executing a transaction and then sends the results to the Ethereum blockchain. zk-Rollups are essentially called Zero-Knowledge because after a transaction is completed, they are sent as a batch back to the Ethereum blockchain with proof that they are valid. These proofs are called short non-interactive argument of knowledge(SNARK). zk-SNARKs are methods used to verify the authenticity of data without revealing the full details of the transaction.
There are two critical components of the ZK-Rollups architecture:
On-chain Contracts: ZK-Rollups are controlled by a smart contract that runs on the Ethereum network. The Ethereum blockchain serves as the main contract, which stores roll-up blocks and sequencing, tracks deposits, and stores the state of the rollup. The on-chain contract also serves as the verifier ensuring the blocks produced by the zk-Rollup.
Off-chain Virtual Machines: The off-chain virtual machine is independent of the Ethereum virtual machine and is where transactions are processed in the zk-Rollup architecture. This ensures less struggle for block space on the main Ethereum network.
Let us now examine what an Ethereum virtual machine (EVM) is:
What is an EVM
The Ethereum Virtual Machine (EVM) is a data processing engine that functions similarly to a distributed computer with large numbers of executable projects. It serves as the virtual machine and the foundation for Ethereum's entire operating structure. It is regarded as the component of Ethereum that handles execution and smart contract deployment. Each Ethereum node runs an EVM, which is updated after each transaction to ensure that the Ethereum network's state is consistent across the system.
Now we have examined the two key concepts of ZKs and EVMs, let us examine what zk-EVMs are:
ZK-EVMs — A deeper dive
ZK-EVMs combine the concept of ZK-Rollups and EVMs. Thus, zk-EVMs allow for the development of dAPPs, maximizing privacy while using the Ethereum virtual machine to process transactions and execute smart contracts.
Types of zkEVMs
There are different schools of thought regarding the execution of zk-EVMs. However, Vitalik Buterin, the creator of Ethereum, has popularised a classification of zk-EVMs. Let’s examine these classifications as put forward by Vitalik.
Type 1 zkEVM
These types of zkEVMs are also referred to as fully Ethereum equivalent. This is because the EVMs are fully equivalent to Ethereum and do not make any changes to the blockchain other than making it easier to generate proofs.
Pro
These types of zkEVms are perfectly compatible with Ethereum and can provide the basis for future zk integrations on the Ethereum network.
Con
The Ethereum network was not originally built to be zk-compatible. Hence the Ethereum network might require a lot of computation to conduct a zk-prove. Thus, these zkEVMs may result in longer prover times and ultimately longer time to finality of transactions.
Some projects building the type 1 zkEVM are the Applied ZKP from the Privacy and Scaling Explorations team and Taiko.
Type 2 zkEVM
Type 2 zkEVM implementation seeks to be exactly like the Ethereum virtual machine but slightly different from the Ethereum equivalent. Type 2 zkEVMs resemble the Ethereum blockchain except for the data structures and the state tree.
Pro
Type 2 zkEVMs have a virtual machine almost equivalent to the EVM and will ensure compatibility with several EVM debugging tools and developer infrastructure.
Con
Type 2 zkEVMs, like Type 1 EVMs, have a slow prover time because the Ethereum blockchain was not originally built to be zk-compatible. However, type 2 zkEVMS have a slightly faster time.
Some projects building type 2 zkEVMs include Scroll and the Polygon Hermez.
Type 2.5 zkEVM
Type 2.5 zkEVMs are named so because they are very similar to the type 2 zkEVMs, except that they change gas costs. Hence, type 2.5 zkEVMs are sometimes referred to as EVM-equivalent with modified gas costs.
Pro
Type 2.5 zkEVMs are considerably cheaper because of the reduced gas cost.
Con
Since there are alterations to the gas costs on the chain, there is a risk of incompatibility with developer toolings available to software creators integrating type 2.5 zkEVMs, and the implementation can break some decentralized applications built.
Type 3 zkEVM
Type 3 zkEVMs vary from other forms in that there are hard limits on the number of times an operation can be called within the protocol. As a result, these types of zkEVMs are sometimes referred to as almost EVM-equivalent.
Pro
Type 3 zk-EVMs are easier to build and have way improved prover times because they typically eliminate features that are hard to implement.
Con
Most protocols currently avoid remaining as type 3 zkEVMs, until they can completely implement features that make them Type 2.5 zkEVMs. Thus, there is a risk of higher incompatibility since most applications need to be rewritten.
In their early form, Scroll and Polygon are said to be Type 3 zkEVMs.
Type 4 zkEVM
The implementation of Type 4 zkEVMs is by using smart contract code written in a high-level language like Solidity and Vyper and compiling the code to be zk-SNARK friendly. Hence, they are referred to as high-level language equivalent zkEVMs.
Pro
Type 4 zkEVMs have very fast prover times.
Con
There is a very high risk of incompatibility while compiling a smart contract from high-level languages like solidity or vyper.
ZKSync and Warp from Nethermind are projects building and implementing the Type 4 zkEVM system.
Final Words
Since the completion of the merge, we have seen a rise in scaling solutions to ensure that Ethereum remains the leading layer of choice for executing decentralized finance projects and other decentralized applications. Thus, we think this topic is critical for the success of web3 in general. However, it is also important to note that several of these solutions are experimental, and the space is rapidly evolving, so we implore you to keep an eye on the space before making any investment decisions.
Thanks for making it to the end of the post. Kindly follow us on Twitter to support this publication.
Further Reading
The Merge:
Vocdoni Documentation: https://docs.vocdoni.io/architecture/protocol/rollup.html
Ethereum Foundation on EVMs: https://ethereum.org/cs/developers/docs/evm/
The different types of ZK-EVMs: https://vitalik.eth.limo/general/2022/08/04/zkevm.html
zk, zkVM, zkEVM, and their Future: https://mirror.xyz/msfew.eth/Yl64OK3lLG48eJpVB3GxqFEhmWOm6yMlAo9sc1VrQP4
zk-STARKs vs. zk-SNARKs: Differences in zero-knowledge technologies: https://blog.pantherprotocol.io/zk-snarks-vs-zk-starks-differences-in-zero-knowledge-technologies/