The EVM
Many see the EVM’s adoption and continued dominance as inevitable. Ethereum has the greatest wealth of infrastructure, tooling, and developers of any ecosystem. About 97% of all TVL in DeFi is in EVM chains, which speaks for itself. This has created a strong network effect around Ethereum, specifically on the EVM.
As a result, several ZK-Rollup projects have been working on implementing ‘zkEVMs’, e.g. an EVM-compatible ZK-Rollup. There is great excitement around this technology, with some going as far as calling it the ‘holy grail of scaling’.
While you may hear the term zkEVM to describe multiple projects, there are many different implementations of zkEVM with different trade-offs regarding performance and actual Ethereum equivalence. This has been confusing, prompting Vitalik to write an article with different classifications for zkEVMs.
Different Types of zkEVM
The differences between zkEVMs arise from trade-offs between proof generation cost and EVM compatibility. These range from Type 1 to Type 4 as defined by Vitalik. Type 1 is the most Ethereum equivalent and with the worst prover performance, whereas Type 4 is the least Ethereum compatible with the best prover performance.
Type 1 is fully Ethereum equivalent, whereas Type 4 is EVM-compatible at the language level. The below diagram shows the trade-offs made between Ethereum equivalence and prover performance:
The EVM was not designed for ZK-proofs and is considered extremely difficult to fully prove. So the closer to EVM equivalence the more complicated the implementation. As a result, there are no Type 1 zkEVMs close to deployment today, and likely won’t be in the near feature.
Most zkEVMs in development are currently Type 3 or 4. Although several are aiming for Type 1 and 2 implementations, the complexity of achieving this means they remain a work in progress. It remains to be seen whether this is desirable or if a design more suited to ZK-proofs (Type 3 or 4) is more optimal. Fortunately, there are several projects taking different approaches to the zkEVM which will reveal what implementation(s) of this technology works best.
Type 1
Type 1 zkEVMs are fully Ethereum equivalent, meaning they make no change to any part of the Ethereum system. This means existing infrastructure can be reused without requiring any changes. If properly implemented, this is the safest zkEVM as its perfect equivalence means application deployment and infrastructure compatibility are seamless.
A Type 1 zkEVM would be extremely challenging to ZK prove, and will therefore be less performant than other systems. In addition, it would lack the ability to implement changes that improve the user experience such as native account abstraction at the L2 level. So full equivalence is not necessarily a good thing. It's likely that high performance would need to come from the L3 level, which remains a hypothetical concept, the limitations of which have not been tested in practice.
There are no Type 1 zkEVMs at present. Taiko has stated the aim of building towards one. Many believe it will take years due to the difficulty in proving the EVM.
Type 2
Type 2 zkEVMs are fully EVM-equivalent but not Ethereum equivalent. This is because they make some modifications to make proof generation faster and development easier. They remove the most complicated ZK-unfriendly cryptography, making them much more performant than Type 1 zkEVMs. This comes at the expense of full Ethereum equivalence; however, almost everything will work the same as at L1. Proving times will still be long due to the general difficulty in ZK-proving the EVM.
Polygon ZK and Linea are building towards a Type 2 zkEVM. Current implementations are more like a Type 3 zkEVM at present as they haven’t implemented several very complex precompiles yet. All these networks are a work in progress, and it will be interesting to see if they can find feasible paths toward EVM-equivalence.
Type 2.5
Vitalik also discusses a Type 2.5 zkEVM which would greatly increase gas costs for the most ZK-unfriendly opcodes. This is because some actions that are easy/cheap in a traditional computational context are much more challenging/expensive in a ZK Circuit. Therefore, if the gas costs weren’t adjusted, a user could write a smart contract that calls a function repeatedly, which ends up tying up the resources without paying the real costs for these resources.
Doing this reduces compatibility slightly but is considered safer than deeper changes.
Scroll is building a Type 2.5 zkEVM.
Type 3
These are considered nearly EVM-equivalent but remove extremely difficult features of the EVM to ZK prove. They still implement the EVM at the bytecode level, making them compatible with most applications and infrastructure.
However, some applications will need to be rewritten due to differences in the precompiles or subtle dependencies on edge cases that the VMs treat differently. This is also true for some EVM infrastructure that will need to be adapted for these zkEVMs.
Scroll and Polygon are currently in this category but are building towards Type 2.5 and Type 2 zkEVM, respectively.
Type 4
These systems take smart contract source code e.g. from Solidity and compile it into a language more optimized for ZK-proofs. An example of this is zkSync which compiles from Solidity into Yul. A benefit of operating this way is that high-level languages more optimized for ZK-proofs can significantly improve prover performance and by effect decentralization because they make it easier to be a prover.
Some of the issues that arise because of this include Ethereum debugging infrastructure cannot work. This is because it runs over the bytecode, meaning it cannot work with Type 4 zkEVMs which do not implement EVM bytecode. Some incompatibilities can be observed with zkSync already, and developers have had to make more modifications when deploying there compared to Polygon zkEVM. Deploying on Polygon has empirically been easy, and this is set to improve as it moves from a Type 3 to a Type 2 over time.
Final Thoughts
Generally, as you move up the tiers (towards Type 4) in zkEVMs, you will have more performant systems but the tooling and complexity for developers will increase. This may cause some serious issues initially, however, satisfactory tooling can be built around this. The same is true the other way, the closer to Type 1 you get, the greater the difficulty in proving. In return, these low-level types inherit more tooling, simplicity, and alignment with Ethereum mainnet.
Note that prover times will not affect the user, as confirmation at L2 will be near instantaneous. However, long prover times are associated with higher costs, which can cause centralization issues.
A number of projects are seeking to maximize compatibility with the EVM. This is a very ambitious endeavour, and it remains to be seen if it is practical in reality. Even Vitalik notes that Type 1 and 2 zkEVMs may opt to become Type 3 in the future to improve performance and functionality. It's important to have a variety of solutions available at this stage to understand which trade-offs are most valuable/important over the longer term.
zkEVMs Today
This section covers zkSync, Scroll, Taiko, and Polygon.
zkSync
zkSync achieves EVM compatibility by having a VM that adapts EVM development tools and works well with validity proofs. It is not EVM equivalent, as Matter Labs have opted for a Type 4 design that is more compatible with ZK proofs.
Design
It is compatible at the language level because it compiles code written in Solidity into Yul. Yul is an intermediate language for Solidity to be compiled to bytecode in LLVM - a compiler framework. This enables zkSync to achieve EVM compatibility but not equivalence. Remember, EVM equivalence can only be achieved if the EVM is implemented at the bytecode level.
Risk
By not implementing EVM at the bytecode level, zkSync arguably adds an additional risk (due to the differences between the two environments). However, it remains to be seen if/how problematic this is. They claim that 99% of code can be deployed directly to zkSync 2.0 without any need for alterations. However, developers are experiencing a little friction at present. For example, $1.7m worth of ETH became permanently locked in a smart contract as the transfer() function on the EVM does not work on zkSync. Note that zkSync developed a solution to unlock these funds, however, it highlights some of its incompatibilities. Some tooling is incompatible at present, but tailored solutions can be built to address this.
Analysis
This design choice reduces the burden on Matter Labs to build a system that is compatible at the bytecode level. In addition, taking a more ZK-friendly approach could set zkSync up for higher performance, which will be required to onboard the masses to crypto rails. More adaption to dApps porting to zkSync is required compared with a bytecode-compatible design. This is the fundamental trade-off - a more ZK-friendly design (thus cheaper and faster proving times and easier path to decentralization) vs EVM equivalence.
Ultimately, zkSync is mostly EVM compatible, with some modifications required for dApps. It is more optimized for validity proofs and this could end up being its key strength as it can both:
- tap into the network effects of the EVM and
- be highly performant due to its ZK-optimized design.
It will be worth closely observing how infrastructure evolves around zkSync. This will be important for the safe deployment and maintenance of apps on the network. Its language-level zkEVM means that some existing tooling is incompatible. Therefore, it necessitates the development of new tooling required for the network. zkSync could thrive if it can prove itself to be the most performant network and has the requisite infrastructure in place for developers to be confident building and deploying there. It remains to be seen whether they will transition towards bytecode compatibility (Type 3) in the future.
It has seen remarkable growth since launching on 24th March 2023
Scroll
Scroll is building a Type 2.5 zkEVM. This means that it will be EVM-equivalent, but it greatly increases gas costs to some of the most ZK-unfriendly components. This approach is being taken as it allows it to retain many existing security assumptions while improving proving times. Early developer activity has suggested that it is extremely easy to deploy applications to its testnet. It implements the EVM at the bytecode level, meaning that most Ethereum infrastructure will work seamlessly on Scroll.
Design
It has achieved bytecode-level EVM compatibility through a modular design, where various tasks are split among different modules. Communication between modules allows computations to be delegated to their sub-modules for the specialization of tasks. Scroll is using a fork of GETH for its block production to achieve near equivalence to a native L1 implementation.
Risk
Risk for developers is arguably lower than that of zkSync due to its greater EVM compatibility (if properly implemented). It is reportedly easy to deploy contracts on Scroll. The real test will be their mainnet deployment, which is now scheduled for Q3 2023.
That said, there is always risk in interacting with any new network.
Analysis
Scroll remains in testnet but is widely regarded as having a strong team. Its EVM bytecode compatibility means that it will be mostly seamless deploying contracts there and the majority of tooling will work. Tooling that does not work can be developed for the network.
It will be interesting to see how performant Scroll will be, especially in comparison to the likes of zkSync. For Scroll to succeed, it will likely need to combine competitive performance at the L2 level, along with a strong L3 ecosystem.
Taiko
Taiko is building towards a Type 1 zkEVM. Many consider this an unrealistic goal in the near term, however, the team appears to be currently set on building towards complete Ethereum equivalence i.e. Type 1 zkEVM. This is a very ambitious endeavour, and it will be interesting to see how the team progresses. They are scheduled to have multiple testnets throughout the year, with the goal of launching mainnet in Q1 2024.
Design
Similar to other zkEVMs, gas fees will be paid in ETH, and block proposers will receive ETH transaction fees. It is planned that block proposers must burn a certain amount of Taiko’s native token (TTKO) to propose the blocks and have their block proposals included in L1 blocks.
Furthermore, when these L2 blocks are verified by provers, TTKO is minted to reward the first successful prover.
Taiko intends to use Ethereum for data availability, meaning that all data is required to reconstruct its state is on Ethereum, giving it Ethereum-grade security and decentralization.
Taiko claims that they are not concerned with the long time to finality associated with ZK proving the EVM, as they can circumvent the need to wait for the proof when at the rollup level - where proposed blocks have the same finality as the enclosing L1 block.
Analysis
It is uncertain whether TTKO will be used for governance, which is actually a contentious issue for EVM-equivalent zkEVMs. Furthermore, its stated aim of building a zkEVM is true, but may take a few years. It would arguably be impressive if they initially launch as a Type 2 zkEVM. Similar to Scroll and Polygon, they will need to be sufficiently performant and develop strong L3 ecosystems to thrive. They are seeking their competitive advantage as being the most equivalent zkEVM, placing their bets on EVM supremacy and that less equivalent zkEVMs will be problematic due to small incompatibilities that could cause serious issues down the road.
It will need to overcome centralization challenges, given the current difficulty with ZK-proving the EVM and the fact that the first prover is the only one that receives rewards.
Polygon
Polygon zkEVM is a Type 3 EVM-compatible zkEVM. It is EVM-equivalent except for contracts that use precompiles. However, there are technical differences where Scroll focuses on a more native implementation while Polygon recreates EVM opcodes that can be deployed as smart contracts for its zkEVM. It uses both SNARK and STARK proofs to achieve this. It is bytecode compatible via an interpreter.
- STARKs are used where it is more efficient - they enable faster proof times than SNARKs
- However, they consume 10x more gas than SNARKs, so SNARKs are used to prove the validity of STARKs in the system.
Design
In the system, there are two key high level processes for the verification of proofs
- Transaction batching (carried out by sequencers)
- Validation of batched transactions (carried out by aggregators)
Sequencers propose batches to the network.
- Sequencers are required to pay a fee in MATIC to create and propose batches.
- Sequencers are rewarded by users of the network.
- It will be interesting to see if the network can generate sufficient sustainable incentives to support decentralized sequencing.
Aggregators produce proofs attesting to the transactions and receive fees from sequencers for doing so.
Polygon zkEVM is aligned with the Ethereum community, with gas fees payable in ETH. The MATIC token is integrated with the system in that sequencers will pay aggregators a MATIC fee. As activity rises, the MATIC fee increases, thus incentivizing aggregators to generate proofs. Aggregators have two costs basis: server costs and L1 transaction costs.
Analysis
Polygon has seen minimal activity on its zkEVM in its early days. It has less than 1% of the value bridged to zkSync, however, this can be attributed to the fact that there is no token incentive for participating on Polygon. zkSync participants are generally there to farm an airdrop, whereas Polygon is not currently expected to have a retroactive airdrop. This includes developers, and a situation similar to Arbitrum could arise where incentives ultimately lead to a self-sustaining ecosystem. Ultimately it will boil down to which dApps choose to deploy there.
If some of the top DeFi protocols select Polygon, then user activity could swing there. It will be interesting to see when the big DeFi protocols deploy to zkEVM and which one they choose. BD is also one of Polygon's strengths, which may help them in this regard, in addition to potentially bringing on new brands/projects to their zkEVM ecosystem.
Potential Issues with EVM Rollups
EVM Fragmentation
There could be some undesirable consequences of having multiple successful ‘zkEVMs’ and EVM-equivalent Optimistic Rollups that are all somewhat different. A situation may arise where these rollups seek to differentiate themselves through new features and optimizations. For example, EVM equivalence does not support native account abstraction yet. This could result in them developing their own versions of the EVM, resulting in increased divergence.
This can result in a fragmentation of the EVM. A core part of zkEVMs’ value proposition is their EVM equivalence, so a departure from this somewhat cannibalizes this (which may be for better or for worse). A fragmented EVM is arguably undesirable, as it introduces some more risk for cross-EVM chain deployments and the overall complexity of the ecosystem.
Liquidity fragmentation
Liquidity fragmentation across rollups is another issue within the ecosystem. zkSync has a vision of having a huge L3 ecosystem with shared liquidity achieved through cryptography via a shared prover. However, this is at this stage an idea, not a reality. The likely landscape for the near future is of multiple different zkEVMs with fragmented liquidity. There are a number of solutions seeking to address liquidity fragmentation, the efficacy of which will only be seen with time.
Governance
Tokens with governance properties is a contentious issue for rollups. If they are positioned as ‘EVM-equivalent’ then a governance token that can take it in a different direction is potentially at odds with this. Token distribution can take a long time, and governance is a potential attack vector for hostile actors e.g. centralized holders, state actors etc. A strong L2 ecosystem governed by a relatively small number of actors could wield power to push through changes at the L1 level to suit its own financial aims.
This report highlights the different trade-offs between the various zkEVM types. It is important that a number of teams are taking different approaches to the zkEVM which will allow us to see which systems work best in practice and manage to onboard users. It will be interesting to observe how projects manage to progress towards closer EVM-equivalence while staying sufficiently performant. The fragmentation of the EVM across multiple rollups will necessitate strong supporting infrastructure to avoid potentially significant security issues arising from a lack of complete equivalence.
