What is zkEVM: Things You Need to Know About The Future of Dapps

Hello fellow web3 enthusiasts! I’m excited to share with you today about a fascinating development in the blockchain space: zkEVM. If you haven’t heard of it yet, zkEVM is a new technology that promises to change how smart contracts are executed on Ethereum and other blockchain platforms and how blockchains can finally start to show signs of mass adoption due to their increased throughput and efficiency. zkEVM adds a new level of security and privacy to decentralized applications by using zero-knowledge proofs (ZKPs) to check that computations are correct. If you have not read my last post about on introduction to zero knowlege proofs, do check it out. In this post, I’ll explain what zkEVM is, how it works, and why it’s important for the future of blockchain technology in this article. So buckle up and let’s dive in!

The problem

We have come a long way from smart contracts to side chains and rollups before arriving at zkEVM as a potential blockchain scalability solution. This issue has been at the center of the vast majority of blockchain developments over the past few years. Current blockchain technology cannot support mass-adoption applications without sacrificing decentralization (a trade-off most L1 blockchains make in order to scale faster). Consequently, scaling remains central to the vast majority of current blockchain discussions. Therefore, there is increasing competition among companies to introduce an EVM-compatible ZK rollup.

The race to launch an EVM-compatible ZK rollup has heated up in the past week. The competition among businesses to introduce an EVM-compatible ZK rollup is intensifying. Example: Polygon announced the mainnet launch date for zkEVM. (Just two days later) zkSync released their zkEVM mainnet. Why is the race? What is a zkEVM. How do I utilise it? Let’s jump right in.

Solutions proposed so far

Most solutions to Ethereum’s scalability problems hurt one of the other two qualities in the scalability trilemma. Typically, “it scales better… but insert drawback here>” is said. Let’s examine each of them:

Sidechains

A sidechain is a blockchain that is completely separate from Ethereum, with different histories, roadmaps, and consensus algorithms. To be considered a side-chain, it must have a two-way bridge connecting it to the Ethereum Mainnet so that data can be transferred between the two chains. Polygon’s proof-of-stake (PoS) is the most prevalent instance of a sidechain. Compared to Ethereum, Polygon PoS has a 10,000x lower gas fee per transaction and 450x higher transactions per second. Polygon PoS is incredible. Adidas, Meta, Stripe, Reddit, and numerous others have selected Polygon as their partner.

 Image source

To achieve this increased throughput, however, sidechains must sacrifice some decentralisation or security. Despite these sacrifices, Polygon PoS has struggled with scalability on multiple occasions in the past. In 2022, for instance, the play-to-earn game Sunflower Farmers caused gas prices to skyrocket after consuming over 40% of the network’s gas fees. Due to the increased demand on Polygon PoS, wallet transactions from users have recently failed due to inaccurate gas estimations.

Rollups

Rollups differ from sidechains in that they are not “separate” from the Ethereum network. Instead, they publish transaction results on the Ethereum mainnet, allowing them to reap the full security benefits of Ethereum. Rollups enable operators to bundle multiple off-chain transactions outside of the main EVM, and then submit them all at once to Ethereum, achieving scalability improvements of 10 to 100 times. On a technical level, these batches are submitted to an Ethereum mainnet-stored “rollup” smart contract, which keeps track of the rollup’s state.

There are two types of rollups currently available:

  • Optimistic rollups
  • ZK Rollups
 Optimistic Rollups

Optimistic rollups such as Optimism and Arbitrum are examples of such rollups. The first kind of algorithms are referred to as “optimistic” because they operate under the assumption that the transactions that they roll up are legitimate by default. They do not publish any proof to Ethereum demonstrating that the transactions are legitimate. Instead, transactions are treated as “innocent until proven guilty,” and a fraud-proving scheme that enables the detection of invalid transactions is part of this system. 

A “challenge period” is made available to parties so that they may contest the results of a rollup transaction by submitting a fraud-proof that can see whether or not a fraudulent transaction took place in that rollup. If one is found, the transactions are redone, and the state of the rollup is brought up to date. The party responsible for submitting the fraudulent transactions will be subject to a penalty, which will function as an incentive mechanism within the ecosystem. This is really exciting to hear. 

Where does the disadvantage lie? Because of this challenge period, which lasts for an unspecified amount of time but is typically close to seven days, you will not be able to conduct this withdrawal to Ethereum mainnet via the bridge until the challenge period has concluded. There is also an element of dependence on the fact that at least one honest person is challenging the current state of the rollup by looking for fraudulent transactions.

 ZK Rollups

We’re getting to the good part now, so hang on. 

In contrast to their optimistic counterparts, ZK rollups do provide proofs of validity for the changes they make to the Ethereum mainnet. These proofs of validity are called “zero-knowledge proofs” because they can be proven true using zk-SNARKs or zk-STARKs without disclosing the contents of the statement provided by the rollup. Since the transactions are verifiable as soon as the rollup contract confirms the validity proof, there is no need for a challenge period. In other words, there is no longer any need to wait to transfer your ZK rollup funds to the Ethereum mainnet.

Wow, that’s incredible! But where’s the catch? However, ZK Rollups are “incompatible” with the EVM, unlike the other solutions we’ve discussed. Unlike the other solutions we’ve described, where you can simply point your Solidity contract at a ZK rollup and send it, this is not the case. When using other solutions, such as Ethereum, Polygon PoS, Optimism, Arbitrum, etc., all you have to do is alter the URL of your deployment script. Therein lies the rub. ZK Rollups don’t let you pull that… Not until now! This is where zkEVMs come in.

What is a zkEVM?

ZK rollups have not been used because they are not EVM-compatible, which makes it very difficult to actually build anything on them. The name “zkEVM” should make sense if you’ve followed my explanations so far. A zkEVM is an EVM-compatible zero-knowledge rollup. When using a zkEVM, developers can reap all the advantages of a ZK rollup while having the same experience as when working with any other EVM chain, such as Polygon or Ethereum. Incorporating the advantages of both approaches, it may be possible to solve the scalability trilemma this way. All currently-deployed web3 dapps can take advantage of this technology by switching the RPC URL in their deployment scripts and sending their data directly to the zkEVM.

While still being EVM-compatible, zkEVMs handle batching transaction execution and publish cryptographic proof that the result of those transactions is correct on the Ethereum mainnet. That means any smart contract that can run on Ethereum or Polygon PoS can now run on a zkEVM. Increasing smart contracts’ and dapps’ scalability significantly Vitalik Buterin, the man himself, has a high opinion of the ZK rollup. “ZK rollups will win out in all use cases in the medium to long term,”, says Vitalik. 

How does zkEVM work?

zkEVMs are the same as ZK-rollups; they are merely an upgrade. The optimal structure and operations of a zkEVM are the subject of numerous theories, which must be acknowledged. To comprehend how zkEVMs operate, we must recognise their diversity, as demonstrated by the variety of projects currently in development. Despite having similar objectives, their approaches differ. The founder of Ethereum, Vitalik Buterin, attempted to classify zkEVMs into four categories and a fifth. Here is his summary of the different types of zkEVMs:

Types of zkEVM as per Vitalik.
Types of zkEMVs as per Vitalik

Type-1 zkEVMs: fully equivalent to Ethereum

zkEVM Type-1s are anticipated to be fully equivalent to Ethereum, with no changes made to their state or transaction trees, hash codes, or other consensus logic. Type-1 zkEVMs will be fully compatible with all Ethereum-native applications, but will require more prover time due to the absence of any special reworking to speed up proof generation.

Type-2 zkEVMs: EVM (not Ethereum) equivalence

Type-2 zkEVMs will aim for EVM-equivalence rather than Ethereum-equivalence, lowering the bar slightly. zkEVM Type-2s will resemble Ethereum from the outside, but will have minor modifications on the inside to facilitate development and accelerate the generation of proofs. Some applications may be incompatible with this type of rollups. Nonetheless, type-2 zkEVMs will continue to have slower prover times. Therefore, Type-2.5 zkEVMs could reduce prover time by increasing gas prices.

Type-3 zkEVMs: departing from EVM

zkEVM Type-3s would not be fully EVM-equivalent because this type prioritises the simplicity of integrating an EVM-like system into ZK-rollups. This includes modifications to facilitate construction and enhance proof generation. Although Type-3 zkEVMs may be compatible with the majority of applications, some may require rewriting.

Type-4 zkEVMs: close cousins to the EVM

zkEVM Type-4s would only correspond to high-level programming languages, not the EVM itself. Bypassing the process of providing zero-knowledge proofs for each stage of EVM execution would reduce costs, encourage decentralisation, and speed up the generation of proofs. However, this would reduce the compatibility of Type-4 zkEVMs with several applications. When migrating applications to the EVM, contract addresses will likely change, and it will be impossible to migrate multiple debugging infrastructures.

How do I build on a zkEVM?

I know this is the main question and many of you are searching for the answers and well written guides. I don’t want to include this section in the same blog post. I will write the separate post so that we can go in depth and check the compatibility of various Ethereum development tools like hardhat, waffle and much more.

If you liked this article, there will soon be many more just like it. Consider following me to be notified as soon as they are available!