The zk-EVM war is currently escalating. You may have observed that new chains utilizing this technology are being launched almost daily, such as zkSync, Polygon zkEVM, Linea, Taiko, and others. Despite sharing the same zk-EVM concept, it is crucial to understand that each chain has an independent implementation.
Therefore, it's vital to comprehend the differences between them before utilizing zk-EVM. This article provides an opportunity for everyone to understand the variations between each chain.
The Rollup war
If you have been familiar with Layer-2 technology in the past year, you may have heard a lot about Optimistic Rollup (OR). OR is the key engine behind the two most popular Layer-2 blockchains, Optimism, and Arbitrum. However, in addition to OR, there is another popular Rollup technology called Zero-Knowledge Rollup, which many in the industry believe could easily overtake OR once it is fully developed.
If you're not yet familiar with the Rollup concept, let's take a step back. Rollup is a scaling solution for blockchains that involves creating another blockchain as an execution layer to process transactions and then saving the data back to the root chain in batches, also known as "Rollup."
As a result, a significant amount of gas can be saved because the transaction processing fee is very low. The majority of gas each user needs to pay is for saving the data back to the root chain, which is now 60-90% less than processing everything on the root chain itself. Despite the lower gas cost, the Rollup mechanism is still highly secure because all data is stored on the root chain.
The Rollup concept is widely accepted as a mechanism that will drive Layer-2 technology, leading to mass blockchain adoption. However, as stated above, there are two major types of Rollup that people are working on: Optimistic Rollup and Zero-Knowledge Rollup.
Optimistic Rollup vs Zero-Knowledge Rollup
Although both concepts share the same "Rollup" term, they differ significantly in their details.
Optimistic Rollup lives up to its name by being optimistic. Once a transaction is processed, the data is saved back to L1 without proof of accuracy. This straightforward approach makes it easy for developers to implement the technology, which is why we've seen many Layer-2 blockchains driven by this technology launched since last year.
However, Optimistic Rollup has some significant drawbacks due to its characteristics. Since the data saved back to L1 is not proven to be correct, the protocol needs to introduce a "challenge period" during which anyone can file a challenge against any malicious data. If the challenge is proven right, the block data of that batch will be reverted. The challenge period is currently set at seven days, which means that a transaction on the Optimistic Rollup chain can be reverted anytime during this timeframe. Once the challenge period has passed, the transaction will be finalized.
The 7-day finality period creates a limitation where users must wait for seven days for any significant action that requires finality, such as the withdrawal function. However, a 3rd party bridge may be an exception as they operate in an "Optimistic" way, believing that no challenge will occur.
The story is different for ZK Rollup.
Unlike Optimistic Rollup, ZK Rollup introduces a zero-knowledge proof that ensures the data's accuracy once it's saved back to L1, allowing for transactions to be finalized in just a few minutes! Once the data is rolled up on L1, it cannot be reverted. Therefore, if you want to withdraw an asset from a ZK Rollup blockchain, you only need to wait a couple of minutes, not days.
It sounds like an ideal solution for Layer-2, doesn't it? Yes, it is. Even Vitalik agrees that ZK will eventually win the Rollup war. But have you ever wondered why none of the Layer-2 solutions equipped with ZK Rollup technology made it to the market in the past year, leaving the dance floor to Optimism Rollup?
Before moving on to the next step, it's important to note that when we talk about Layer-2 in this context, we are referring specifically to Ethereum Layer-2, which is the scaling solution for the Ethereum mainnet. The Ethereum Virtual Machine (EVM) is the primary key element that must be fully supported in order to achieve the mission of scaling Ethereum.
Optimistic Rollup works similarly to the Ethereum Mainnet, with a few small differences that allow the Optimism Rollup chain to adopt Ethereum's EVM directly. However, it's a different story for the ZK Rollup chain, as the EVM was not designed with ZK-Proof computation support. Therefore, these chains need to develop their own EVM-compatible that supports ZK-Proof, commonly called zkEVM.
The Challenge of zkEVM
Although zkEVM sounds like an ideal solution for Layer-2, a significant amount of work is required to make it a reality. As previously mentioned, Ethereum's EVM is not designed for this type of technology, so a new EVM must be developed to support it. This is why ZK Rollup Layer-2 was not available until last month.
While some of these zkEVMs may already be functioning properly, they are still far from perfect.
The first area that needs significant improvement is gas cost. You may have noticed that the gas required for zkEVM is much higher, around 4-10 times that of what is required on Optimism Rollup chains. Why is this?
Unlike Optimistic Rollup, which simply saves the data back to L1 without any data processing, ZK Rollup requires execution on L1 for validity proof on every batch, resulting in additional gas required on ZK Rollup compared to Optimistic Rollup.
This high gas fee may be a significant barrier that blocks ZK Rollup chain adoption since gas fees are a key factor why people use Layer-2 as a scaling solution. However, we believe that improvements on both the Layer-1 and Layer-2 sides will help alleviate this issue over time.
However, there is still another big challenge, which might be even bigger than the gas cost.
Each zkEVM all works differently.
Since zkEVM is a new technology and each team working on it needs to build things separately, none of the zkEVM solutions (such as Linea, zkSync, Scroll, Taiko, etc.) work in exactly the same way.
At the current stage, the same code that works on chain A might behave differently on chain B or other chains, creating a potential security flaw that hackers could exploit to attack the smart contract of each chain.
Therefore, it is necessary for anyone who wants to use zkEVM to understand the differences between each solution since knowledge is the only thing that will help protect your valuable assets.
4 Types of zkEVM
zkEVMs are not all the same but can be categorized into four types.
🟢 Type-1: Full Ethereum-Equivalent
Everything behind Type-1 zkEVM is fully equivalent to Ethereum. The term "Ethereum-Equivalent" means that everything is equivalent to Ethereum, including state trees, hash codes, consensus, and more. The advantage of this is that we can expect everything that already works on Ethereum to work perfectly on Type-1 zkEVM. The major drawback is that since Ethereum is not ZK-friendly, the time required to do the validity proof is high and not very efficient.
It's worth noting that, once the genius behind Type-1 zkEVM has resolved all concerns, it will not only benefit Layer-2 solutions but also provide a big advantage to Layer-1 itself by adopting the technology to scale Layer-1 further.
The only Type-1 zkEVM currently available in the market is Taiko. Taiko has been attempting to overcome the concern of proof generation time by designing its protocol to bypass the need to wait for a proof when on the rollup, leaving the proof only for cross-chain transactions like asset bridging.
Taiko is still in the Alpha-2 stage and has a lot of work to do, but it's worth following their progress since there aren't many teams working on Type-1 zkEVM.
🟢 Type-2: Fully EVM-Equivalent
In reality, making zkEVM an Ethereum-equivalent is a tough task due to the structure of Ethereum itself. Instead of being an Ethereum-equivalent, Type-2 zkEVM aims to be an EVM-equivalent, making everything on its EVM work identically to Ethereum's EVM and using its own design for other parts of the Ethereum stack, such as state trees, to increase efficiency in validity proof.
The significant advantage of this type is that everything at the VM level is identical, meaning that smart contracts and already-existing dapps can be deployed and work perfectly on the chain of this type.
There are currently many promising Type-2 zkEVMs on the market, including Scroll and Polygon zkEVM, both of which have delivered chains with the impressive performance thus far.
🟢 Type-3: Almost EVM-Equivalent
Type-3 zkEVM sacrifices some EVM behavior for faster proof generation, making it an "Almost" EVM-Equivalent. Due to its non-EVM-equivalent nature, developers who build a dapp on this type of zkEVM need to thoroughly check if their smart contract code works as expected on the chain. Some minimal modifications might be required to make it work perfectly.
It's worth noting that nobody wants to be a Type-3 zkEVM. It's more like a transitional stage of a zkEVM before it becomes a Type-2 zkEVM.
Scroll and Polygon zkEVM started as Type-3 and were continuously improved until they finally reached Type-2 as of today.
🟢 Type-4: High-Level-Language Equivalent
Out of all these types, Type-4 zkEVM is entirely different. Type-4 offers its proprietary VM that executes its own set of opcodes. The only relation to the EVM is at the high level, as they would provide a toolchain capable of compiling smart contracts written in popular languages like Solidity or Vyper to work on their VM.
But you can NOT expect it to be working exactly like it does on another EVM-Equivalent chain.
This type of zkEVM has been entirely built from scratch, having its own runtime. The advantage is that it should be the most efficient zkEVM since it eliminates all existing elements for something completely new. However, there are some major trade-offs to consider, as the code may not always work as developers expect, and this could potentially lead to things breaking on these chains.
Both users and developers need to exercise caution when working or using this type of zkEVM. More information can be found in the sections below.
zkSync Era and Starknet are examples of this type of zkEVM.
Keywords: EVM-Compatible vs EVM-Equivalent
It's important to distinguish between two terms when it comes to zkEVM: "EVM-Equivalent" and "EVM-Compatible".
EVM-Equivalent - An EVM-Equivalent chain works perfectly and identically to Ethereum's EVM. The same code would be working the same way it does on Ethereum.
EVM-Compatible - This type of zkEVM provides support for many EVM elements in some way, but not all. Therefore, you cannot expect Solidity code to work exactly the same way on these chains.
When starting to work or use any zkEVM, it's important to determine if the chain is EVM-Equivalent or EVM-Compatible, as it makes a significant difference in every way.
Why it matters to understand the difference between each type?
You might think,
"Well, I am just a user. I don't need to know how these things work. I'll just use it!"
But this mindset is entirely wrong if you want to interact with zkEVM. You may not require a deep level of technical knowledge, but you need to know enough to understand the risks involved, as it could potentially cost you some fund.
As a developer
It is important to realize that while a code might be functioning seamlessly on Ethereum for years, it may not work the same way on an EVM-Compatible chain.
Therefore, it is crucial to test everything meticulously as a single break in the code could cause a significant incident, potentially costing the ecosystem millions of dollars.
Testing on the local environment such as Ganache is insufficient to ensure everything works as expected. The only way to truly verify that everything is functioning properly is to test comprehensively in a live environment, either on testnet or mainnet.
It's important to keep in mind that your Solidity code might not work as expected on zkEVM chains. Instead of assuming that everything will work flawlessly, it's best to adopt the mindset that "your code might not work on zkEVM." This will help you take necessary precautions and test thoroughly to minimize potential risks.
If you have automated tests, make sure to run them on the testnet chain as the test results may vary depending on which chain you're running them on.
As a user
It is crucial to realize at least two things as a user.
zkEVM might be coming up with plenty of serious bugs since it is not yet mature.
Not all blockchain developers are aware of compatibility issues, and many still expect everything to work the same on every single chain, especially during times like these when new blockchains are being rolled out on a weekly basis. As a result, some smart contracts may have been deployed with security flaws caused by code misbehavior, which allows attackers to exploit and cause damage to users.
A piece of advice to consider is to avoid storing a significant amount of assets on these chains until they are more mature and stable. This is because there is a risk of losing everything due to potential compatibility issues and other related problems that can arise from working with new and untested systems.
🔴 Real case: 921 ETH stuck on a zkSync Era smart contract
There was an incident that occurred just last week, which resulted in 921 ETH becoming stuck in a smart contract on zkSync Era.
198
The root cause of the incident that caused 921 ETH to be stuck in a smart contract on zkSync Era was quite straightforward; it was caused by calling the deprecated function payable(.transfer()) to withdraw the ETH. Although it is not recommended to use this function to transfer ETH on production anymore, it still works on EVM-Equivalent chains, even on Type-2 zkEVM like Scroll. However, this is not the case for Type-4 zkEVM.
Although the issue occurred because the smart contract was calling a deprecated function, it is a real-world example of how compatibility issues can cause damage. This problem was eventually resolved with the assistance of the zkSync team, but there is no guarantee that things will end well next time.
Key Takeaways
It is important to be aware that each zkEVM is different and not all are created equal.
It is crucial to understand the difference between EVM-Equivalent and EVM-Compatible chains.
Always be informed of which zkEVM is EVM-Equivalent and which one is EVM-Compatible before using them.
Realize that there is a level of risk involved with using zkEVMs, which could potentially result in the loss of your funds due to various reasons.
Reference
The different types of ZK-EVMs - Vitalk
