An overview of the progress of major zkEVM projects in 2023

Author: Alex Connolly, co-founder and CTO of Immutable; Translation: Golden Finance xiaozou

In August 2022, I wrote a blog post about the current development status of zkEVM, titled "ZkEVM, EVM Compatibility and Rollup Basic Guide" (Ground Up Guide to zkEVM, EVM Compatibility and Rollups). In the same week, Vitalik published an article introducing different types of zkEVM and establishing the Type 1 and Type 2 classifications. Nowadays, different Type classifications are usually used to refer to different zkEVMs - the competition is very fierce!

In that blog post, I made the following prediction:

...You should also have a clear understanding of the current status of the smart contract rollup. Each team has a strong incentive to market themselves as the one who is about to take over the world - but not until the earliest >Production-level smart contracts will not appear on Ethereum until the end of 2022, and many of these teams will not appear until 2023 Will be ready later in the year.

We have now reached the "end of 2023" - how is the development and adoption of zkEVM? This is a big year for zkEVM in many ways:

· Polygon zkEVM, Linea and Scroll released!

· Immutable announces the next rollup - Immutable zkEVM

· Polygon Announced plans to upgrade Polygon PoS to zkEVM Validium

· Optimism stated plans to support OP Stack chain running as zkEVM

No matter what, the data is self-explanatory:

In short, development of zkEVM is ongoing, but None of thezkEVMs have seen huge adoption yet compared to existing blockchains. The purpose of this article is to answer an obvious question -How are the various zkEVM projects progressing, and how can they generate welcome attention?

First of all, let us quickly review Buterin’s “zkEVM type” to help understand the zkEVM project:

This may look complicated, but it's actually easy to understand. Everyone initially thought in their mind that zkEVM just takes an existing Ethereum execution client (e.g. Geth, Nethermind, Erigon), generates zk (zero-knowledge) proofs of its execution traces, and uses these proofs to secure L1-L2 message bridging . However, the original design considerations of the EVM did not include proof-of-zk, and this approach is very inefficient (e.g., Ethereum’s keccak hash function is expensive). So, we have a few options:

· Type 1  – Just handle it, my users/I will pay . There are two main advantages here: you can use an existing blockchain’s Type 1 Prover, and you don’t need to maintain your own Ethereum client (development costs can be as high as proof costs), but you do have to maintain Perform client updates.

· Type 2 -- does not touch the "application layer" (e.g., does not change opcode cost/implementation) , but change the on-chain nodes to have an internal structure that is more friendly to the prover (for example, use a Sparse Merkle tree to represent the state). A big disadvantage of this approach is that you need to maintain a permanently forked Ethereum client. Considering that Ethereum already struggles to maintain multiple production-grade clients, this is a very important task that requires a dedicated team of blockchain engineers.

· Type 3 – Complete all the work in Type 2, modify the EVM at the same time, and remove the most difficult to prove part (e.g. some rarely used precompilation), which may increase the opcode cost of prover-intensive operations. This is the fastest way to get your prover to market, but you'll need to do all the client updates mentioned above, and experience incompatibilities with existing Ethereum apps and tools (e.g. any contracts using these precompilations will break ).

· Type 4 --Create a custom VM designed for efficient zk proofs, and create and run the A custom guest for the VM. This will significantly reduce verification costs, but requires building a large ecosystem of tools and infrastructure to support your custom VM/guest. You may be able to provide some form of Solidity code conversion, but developers may have to make substantial changes to their existing contracts and tools to deploy on your chain. In my opinion, most Type 4 rollups are not true zkEVM - "smart contract zk-rollup" might be a more accurate description.

It may be easier to understand in table form:

By the end of 2023, almost every active project Both are Type 3 or Type 4 rollup for one simple reason: they are much faster to build (at the expense of compatibility and ever-increasing maintenance overhead)! Interestingly, almost all projects that are currently Type 3 plan to eventually become Type 2 or Type 1 rollups to improve their compatibility with Ethereum and potentially eliminate the need to develop their own clients.

In last year's blog post, I mainly focused on how various zkEVM teams designed their provers. This year, I wanted to cover other important aspects of each project's approach, including those that are not often discussed (such as each zkEVM execution client plan). For example, many people think of L2 as a "sequencer" and prover, while the standard zkEVM design actually looks more like this!

There are other sequencer designs (which we will discuss later), but most zkEVMs currently plan to run a separate blockchain as an L2 sequencer, with Own execution client (receives and executes transactions) and consensus client (reaches consensus on transaction order across all L2 nodes).

Importantly, there is a cost to modifying the standard Ethereum client to create your own custom chain. Every Ethereum client change (especially every hard fork) will be a governance decision for all zKEVM teams. The more parts you customize, the harder it is to make upstream changes. Over time, it is easy to develop zkEVM asynchrony - at a certain point a zkEVM that matches Ethereum will quickly fall out of sync.

1, zkEVMProject status

So, what about those projects we discussed last year?

(1) Polygon zkEVM (and Polygon CDK chain)< /p>

Polygon zkEVM was launched on the mainnet in March 2023 and has processed nearly 10 million transactions so far. It is currently a Type 3, with the goal of becoming a Type 2 sometime in 2024.

Of course, as Type 2/3, Polygon zkEVM requires its own custom client implementation. Polygon chose to build its own client (zkevm-node) from scratch for compatibility, but this new client has experienced outages and lacks many features found in standard Ethereum clients.

To remedy this, Polygon is working with gateway.fm to modify Erigon (formerly turbo-geth) to support the changes required for Type 2/3 provers. This will provide Polygon zkEVM with a more stable base layer and more optimized performance, although maintaining compatibility with upstream Erigon remains an ongoing challenge.

Many teams have also announced that they will use the Polygon Chain Development Kit (CDK) to build zkEVM, including Astar, OKX and Palm Network. The vision of Polygon CDK is to support developers to build their own custom chains according to their needs by combining different clients, provers and data availability solutions (i.e. building their own zkEVM toolkit). Today, the CDK supports a client implementation (zkevm-node) and a prover (Polygon zkEVM). In the future, the Polygon team plans to add more client implementations (such as Type-2-Erigon) and provers (such as Polygon Zero) to the CDK.

This means you can deploy your own version of Polygon zkEVM today! However, any team deploying with zkevm-node may need to migrate to other clients in the future, so may want to wait until they are ready.

We should also note that Polygon is planning to upgrade Polygon PoS (one of the largest and most successful blockchains in the world) to a blockchain with off-chain data zkEVM, but the specific upgrade schedule has not yet been determined.

(2)Scroll

In 2023, Scroll launched two testnets and one mainnet (October) - this is the year of large-scale construction! Scroll is currently a Type 3 zkEVM. They have previously stated that they intend to convert to Type 1/2 in the future, but the specific time is unclear. They have a list of differences from Ethereum, which includes some unimplemented precompilations and some minor state modifications. Scroll's client is a fork of Geth v1.10.13 and currently runs in single sequencer mode. It’s worth noting that parts of Scroll’s execution client are already two years behind upstream Ethereum (although they have chosen EIPs for the Shanghai execution client to reduce application layer bias). This does not cause any direct disruption to the chain, but is indicative of the governance challenges many projects will face in determining how close to upstream Ethereum can be in the long term, and how much engineering effort is required to continually close that gap.

(3)Immutable zkEVM

Since July, Immutable zkEVM has had a public test network and plans to launch the main network in January. Immutable zkEVM uses a version of the standard go-ethereum client that has been customized for our core domain (games). Interestingly, the Immutable zkEVM is the only domain specific zkEVM discussed in this article so far, although the ability of L2 to be customized to domain-specific requirements while maintaining the security of Ethereum is a major attraction of them. For example, Immutable zkEVM is content to use validium data availability to reduce costs and chooses a single-block finality PoSBFT design to provide near-instant confirmations, decisions that may not be suitable for general-purpose chains. In addition, if a large number of games and game users flock to this chain, there may be a network effect - we expect more domain-specific L2s to emerge in the future.

However, the release of this chain will not provide prover support. This is because Immutable zkEVM plans to adopt Type 1 Polygon Zero provers once they are available and cost-effective. The only way for Immutable to release Type 3 is to make substantial changes to the client, which we are unwilling to do given the impact of the client straying away from Ethereum. Today, Polygon Zero is powered by Plonky-2, with Plonky-3 under active development and expected to reach production grade in mid-to-late 2024, which will improve performance by about an order of magnitude. This will provide Polygon with two independent provers (Polygon Zero and Polygon zkEVM), and developers will be able to choose which prover to use in their CDK-based chains.

(4)Linea

Linea released their mainnet in August and adopted a similar approach to Polygon/Scroll: starting with Type 3 rollup and gradually moving to Type 1 or Type 2. Linea currently differs from Ethereum London in only a few ways, as shown in the table.

Linea is using their own updated version of Geth, which they named "zkGeth". It's worth noting that the source code for this client is not open source, nor is the prover - users cannot verify that they run as expected. They plan to open source all of these components as part of their well-documented decentralization roadmap. Linea's documentation indicates that they plan to move from "zkGeth" to linea-besu, an updated version of the Besu client developed by Consensys. In the medium term, the Linea team plans to merge linea-besu and regular besu, and rely on Besu's plugin system to make the necessary state modifications to become a Type 2 zkEVM.

（5）Taiko

Taiko is polishing their fifth testnet and plans to launch the mainnet next year. Taiko is developing their own zk prover based on PSE implementation (similar to Scroll). Interestingly, Taiko is the only team in this article that currently does not consider the design pattern of gradually decentralizing a single orderer into an L2 blockchain. Taiko's design is based on the concept of Based Rollup described by Justin Drake - rather than having a permissioned set of validators, anyone can submit transaction packages and proofs to Ethereum L1. This implementation means that rollup completely delegates ordering to Ethereum L1, allowing it to automatically inherit the liveness and decentralization features of Ethereum L1. However, it has an important drawback: the L2 sequencer does not provide "fast finality" confirmation, which means that users wait longer for transaction confirmation. Justin Drake proposed a "Based preconfirmations" mechanism to provide probabilistic confirmations with a latency of only 100ms, but it was not close to production levels and introduced a separate "preconf (preconfirmation) commitment" and "preconf tips" system There may be an impact on existing Ethereum tools. This is an active area of ​​research!

Taiko has stated from the beginning that they plan to become a Type 1 zkEVM. They believe that the compatibility differences brought by other zkEVMs will be worse than the higher cost of proof generation, and in any case, as the technology advances, the cost will eventually decrease. Taiko's client implementation is interesting - the core "execution client" is a modified Geth v1.13 (taiko-geth). However, they also maintain their own "consensus client" (taiko-client), which handles communication with L1 and monitors the based ordering process.

(6)zkSync Era

The zkSync Era was released in March 2023 and has been a success so far, with rumors of an upcoming airdrop pushing its TVL to over $500 million. zkSync is a Type 4 zkEVM, they are proofing their own custom VM (eraVM) rather than trying to modify the EVM directly. They aim for "language-level compatibility" with Ethereum and provide a direct compiler from Solidity code to their custom VM. They made substantial changes to the implementation of many key EVM opcodes, and also made some changes to the compilation process, so developers often need to modify their contracts or deployment scripts to deploy on the zkSync Era.

zkSync Era has its own custom client, allowing them to implement non-EVM features such as native account abstraction. In July 2023, they upgraded prover to "Boojum", which is a STARK proof system, and then uses SNARK packaging for on-chain verification, similar to Polygon zkEVM. The zkSync Era requires fully on-chain data, but they plan to introduce a “zkPorter” in the future, which will allow users to choose between different data availability models at different price points, similar to the Volition model proposed by StarkWare.

(7)StarkNet

StarkNet is one of the most ambitious projects in the Ethereum ecosystem: they are building a Type 4 rollup and ecosystem from scratch, which includes a new VM (CairoVM), a new programming language (Cairo), a new prover (Stone) and new clients (Pathfinder, Papyrus, Juno). StarkNet will gradually open in 2021 and 2022, and now has more than 150 million US dollars in TVL and a monthly processing volume of more than 10 million transactions.

Building a new ecosystem from scratch is extremely challenging, but also provides fundamental innovation in areas where EVM has been working hard (such as native account abstraction) opportunities and significantly improved performance. Much of the toolchain has been extensively tested through StarkEx-based projects such as Immutable X, dydx v3, and Sorare, which have been running since 2020 and have been widely adopted.

Initially, the StarkNet ecosystem explored language-level compatibility through projects like the Warp Solidity→Cairo translator I mentioned last year. However, Warp is now deprecated and the StarkNet ecosystem has decided to fully commit to the new CAIRO toolset and no longer support any kind of Solidity backwards compatibility. Now, they face the same challenges as non-EVM ecosystems like Solana or Sui - can you get a large number of developers to adopt your new tool? Or will EVM prevail in general?

The work being done by the Kakarot team is the only exception. They are developing a Type 2.5 EVM using the CAIRO language, which will serve as a set of contracts running on StarkNet. . Through Kakarot, users will be able to deploy and interact with EVM contracts that have code/state on StarkNet, allowing users to benefit from the performance of StarkNet while retaining EVM compatibility. Since the underlying execution environment will still be StarkNet, this will sacrifice Ethereum tool compatibility - but for some projects, this may be an acceptable trade-off. Kakarot is not yet at production level, and the performance and tool compatibility impact of this layered approach is unclear, but it is an exciting attempt to bridge the gap between the various zkEVM types and shows that we are exploring In terms of design space, we acted very early.

（8）Optimism

For obvious reasons, Optimism is often thought of as a team focused on optimistic rollups. However, they have repeatedly stated that they plan to support zero-knowledge proofs in ZK as an option in the future, and have had lively discussions with several actively contributing teams. Exciting zk ecosystem projects like zeth now offer Optimism block support. However, we haven’t seen any official timeline or design yet – perhaps there will be exciting changes in next year’s zkEVM review!

As you can see, there are big differences between kEVM teams. Even rollups of the same type often have completely different designs from their provers, clients, and sorting mechanisms.

There is another very important way to compare these new zkEVMs - their actual configurations! In general, it is more interesting to analyze the architecture of each chain's clients and provers because it involves fundamental design decisions rather than application-level configurations that can be easily changed. However, if you are an application developer, the specific configuration is undoubtedly important, so make sure you research the block time of each zkEVM, the block gas limit, the frequency of proof release, the sequencer consensus mechanism and any possible Factors that influence application user experience!

To sum up: In 2023, a variety of teams conducted a lot of development work. So, if things are moving forward, do we just have to wait and see? What other problems do we need to solve to see zkEVM gain substantial traction?

What are the unresolved issues in the development of 2 and zkEVM?

First of all, there is a lack of standardized interface between the client and the prover. Currently, each prover is only compatible with the client they were originally built with. You cannot use Polygon zkEVM's prover with any other Type 2/3 client. Ideally, any new prover or client should be compatible with as many existing provers/clients as possible. Encouraging various zkEVM teams to follow the EIP of a single interface is a critical step for future development.

Understandably, most teams are currently prioritizing improving their own deployments rather than seeking compatibility with others. This may be acceptable for now, but eventually we would like L2-ordered zkEVM in particular to use a multi-client/prover setup to reduce the risk of significant bugs. Additionally, standardizing implementations of "classic" type 2 features (e.g. Sparse Merkle trees, Poseidon hash functions instead of keccak) might help multiple provers use the same or similar clients. Reducing the number of "geth" clients would be a huge win for the ecosystem! A standardization initiative called "RollCall" has been proposed, along with a series of Rollup Optimization Recommendations (RIPs), although it is unclear how widespread this initiative will be.

Secondly, these zkEVMs are almost all single sequencers, which poses a challenge to the decentralization and security of these rollups. In particular, note that the prover's behavior is only to ensure that the L1-L2 bridge is secure. Any external system that relies on L2 pre-confirmation (like CEX) puts a lot of funds at risk because they rely entirely on a single sequencer - for many of today's L2s, a very damaging hack only requires This can be accomplished by stealing a sequencer key. However, once you decentralize the sorter, different challenges arise (as you can see in the Taiko content above!). Do you need to provide a zk proof to L1 to prove that L2 consensus has been reached? What about activity issues? What about MEV? Most single sequencer rollups currently do not utilize MEV for brand/reputation/chain trust reasons, but this may change in the future.

Third, there is no standard framework for measuring zkEVM performance and cost. Much of this article has been spent comparing the potential performance impacts of various zkEVM designs, but currently few zkEVM teams have published any real performance specs or tests. "zkEVM cost" consists of the following parts:

· Cloud computing cost to generate the proof (affected by circuit efficiency)

· L1 cost of verification proof

· Data availability cost

· The cost of sending information from one layer to another

I should be able to create standardized tests for these areas and put The results are tabulated to help builders make more informed decisions - something that is currently not possible. Here's the nuance: some prover implementations will be better than others for certain types of transactions, and part of the cost will depend on usage, due to the ability to spread transaction costs across the transaction package. How these costs should be presented to users is also a big uncertainty (e.g., Immutable zkEVM plans to pay release costs for users in most cases, while Scroll has a complex L1 + L2 charging setup to ensure that every transaction are all profitable). Additionally, many zkEVMs may experience performance issues related to state growth - expanding the Ethereum block space is not free! All of this will require greater measurability/comparability than is currently available.

Fourth, for most smart contract rollups, the exit mechanism is still not well understood and defined. Self-hosting is well defined on a specific application rollup (like Immutable X) - any assets you deposit into that L1 bridge should be retrievable, even if the sequencer is completely offline or completely malicious. This is often called an "escape hatch." But what does this mean in the context of smart contract rollup? What if your ETH is staked in a contract that shouldn't be available anyway? Is this all about censorship resistance (do we need to guarantee the ability to force transactions)? What level of data availability is acceptable for zkEVM used for different purposes (e.g. gaming assets vs. DeFi)? We need a consistent framework to communicate actual failure conditions to users - L2 Beat is a good start in this regard!

Fifth, the relationship between zkEVM and Ethereum L1 is still unclear. While writing this article, I was once again attracted by a blog post published by Buterin that reflected on "enshrined zkEVM". The main takeaway is that the Ethereum client layer can "enshrined" the zk prove implementation, which can be used to verify the execution of EVM blocks submitted by other sources (such as L2). This avoids having to keep all L2 zkEVM provers up to date (big win!) - they can rely on the work of other teams, including the core Ethereum client team, and a fully SNARKed Ethereum has become Reality. So, should I interpret the “enshrined zkEVM” proposal as a departure from Ethereum’s L2-centric scaling roadmap, bringing back the value captured by L2?

Not exactly. L2 still needs its own sequencer to provide fast confirmations (critical in areas such as games), and the design proposed by Buterin only supports zkEVM with fully on-chain data. Most L2s almost want to remain independent for reasons such as monetization, which is an important trade-off for the Ethereum ecosystem. L2 is critical to the expansion of the Ethereum block space, but their motivations (and the BD team) may not always align with Ethereum.

Finally, multiple zkEVMs will continue to disperse users and liquidity, resulting in a poor user experience. Today, each additional Ethereum L2 will continue to decentralize state and liquidity - if you have 2 ETH on Arbitrum, accessing ETH on any other L2 will be difficult. In my opinion this is the best argument yet for monomer chains, where composability is greatly improved and users don't have to balance between multiple chains. With the current popularity of "L2 toolkits" (e.g. Polygon CDK, Arbitrum Orbit, OP Stack), launching a chain has never been easier, but at the cost of greater fragmentation.

For this multi-L2 model to be successful in the long term, in most cases we need to abstract the individual chains and balances away from the user. This is one of the stronger arguments for proofs of validity over proofs of fraud – proof-of-immediacy verification for fast inter-chain bridging. However, even with a strong bridging/interoperability framework, there are still a lot of user experience issues that need to be solved. At Immutable, our plan is to solve this problem through Immutable Passport and vertical integration at the wallet layer.

3, Conclusion

For zkEVM, 2023 This year will be an important year for both development progress and preparation for practical adoption. 2024 will be the first year that Type 1 and Type 2 zkEVMs are truly ready for production use, but realistically we won’t be able to use them until Q3/Q4 at the earliest – there’s a lot we need to solve to get there Performance issues!

I want to make it clear that the main problem zkEVM will solve in 2024 is not a technical problem (although we obviously still have some technical problems to solve), but Value question - can we create exciting applications for users on next-generation L2? We need great protocol developers and great application developers!