Anyone who has used Ethereum during times of peak demand will know first hand how expensive transaction fees can become. When Yuga Labs dropped their Otherdeed NFT collection back in April 2022 there was so much demand, the entire Ethereum network quickly became unusable. Users were paying thousands (in some cases tens of thousands) of dollars in transaction fees. Multiples of the value of the actual asset they were trying to secure.

Needless to say, if we want the next generation of AAA games to build on Ethereum, this is an unacceptable user experience. The number of active users on Ethereum pales in comparison to some of today’s popular games. According to Etherscan, throughout 2022 the number of daily active addresses on Ethereum fluctuated between approximately 300k and 650k. To put this into perspective, World of Warcraft has around 600k to 850k daily active players. 

ZkEVMs are the topic of this post, however they are just one type of scaling solution for Ethereum. Therefore, before diving in we wish to touch on a few core areas to help the reader understand where zkEVMs fit within the wider ecosystem. Some scaling solutions involve altering Ethereum’s core architecture, e.g., sharding, and sit within the Ethereum roadmap. Other solutions typically involve offloading execution and data storage to a separate network. Sidechains like Ronin allow users to bridge assets to a completely separate blockchain but are responsible for their own security. Layer 2 solutions can still be thought of as separate protocols but they leverage Ethereum’s security in varying degrees. These include state channels like Raiden Network, optimistic rollups like Arbitrum and Optimism, and zero-knowledge rollups like Starknet and zkSync.

The most widely adopted scaling solution today are rollups. At a high level, a rollup chain is a separate protocol whose state is managed by a smart contract on Ethereum. This allows rollups to inherit Ethereum’s best-in-class security model and differentiates them from sidechains, which need to bootstrap their own validator networks.

Users bridge funds to a rollup by locking assets in the rollups contract on Ethereum. They can then transact with other addresses within the rollup state by sending transaction data to the sequencer node(s). The sequencer node(s) orders, executes and compresses thousands of transactions down to a single transaction representing the cumulative state transition and commits it back to Ethereum. This is a very efficient way of using blockspace on Ethereum and it amortizes gas fees of the batched transactions making rollups much cheaper to transact on than Ethereum layer 1. 

There are two main types of rollups, optimistic and zero-knowledge (aka validity rollups). ZkEVMs fall under the latter. When a rollup submits a batch of transactions to Ethereum, there has to be some sort of mechanism to provide the assurances needed for finality. This is where the two rollup types differ.

Optimistic rollups assume all transactions in a batch are legitimate. This is of course a big assumption to make, as public blockchains are highly adversarial environments. To combat this, optimistic rollups have a lengthy time to finality (1 – 2 weeks), referred to as a challenge period. During this period, if a network participant suspects an illegitimate transaction has taken place they can submit a fraud proof. The rollup protocol will check the fraud proof, and if upheld, the transaction(s) in question will be re-executed to generate a new rollup state. Additionally the sequencer responsible will face a financial penalty and the provider of the fraud proof will receive a financial reward. This game theoretic mechanism is unique to optimistic rollups. However, because the state may need to be recalculated, optimistic rollups have to post more data to Ethereum than a zkRollup would. Data storage accounts for the majority of all fees on Ethereum, so Optimistic rollups are not the cheapest option. However they’re still orders of magnitude cheaper than transacting on Ethereum layer 1. 

The challenge period is why there is typically a 1 – 2 week withdrawal wait time for users exiting the rollup. There are bridging protocols such as Hop that provide exit liquidity to enable users to withdraw immediately. However, these solutions typically don’t have adequate liquidity to facilitate high volume token withdrawals or NFTs. 

Like optimistic rollups, transactions within a zkRollup are batched, ordered and executed by a sequencer node. However, a zkRollup also creates a validity proof and submits it to Ethereum alongside the state transition data. Without getting too into the weeds, this validity proof is generated by a proving circuit, which is a way to represent a computation mathematically using a series of arithmetic gates. An EVM transaction execution trace is a sequence of distinct computations (opcodes). If each step of the execution trace satisfies the constraints set out in the circuit, we can say with mathematical certainty that it executed correctly. This is repeated for every transaction in the batch. 

As already mentioned, the end result is a new rollup state and a validity proof. However, in order for this new state to be finalized, the protocol has to submit state transition data and the proof to the verifier contract on Ethereum layer 1. If the proof satisfies the verification process, it proves mathematically that there is a sequence of valid transactions that transition the rollup from its previous state to its current state. Importantly this can be done without having to re-execute each transaction in the batch.

Because transactions are mathematically proven to be valid, finality is reached as soon as the proof is verified and the Ethereum block is validated. This enables users to promptly access withdrawn assets, boosting capital efficiency. ZkRollups do not need to be able to “rewind” illegitimate transactions, so have a smaller data footprint on Ethereum layer 1. This leads to decreased fees for users compared with optimistic rollups.

The following section discusses the main projects being worked on and classifies them using Vitalik Buterin’s taxonomy of zkEVMs. This is not intended to be a deep-dive on any particular implementation. Our goal is to provide a framework to guide founders towards a zkEVM solution that suits their needs.

When designing a zkEVM there is a tradeoff between compatibility with Ethereum and the performance of the zkEVM. As already mentioned, some parts of the EVM are not zk-friendly. To optimize proving speed, these components can be swapped out for more zk-friendly equivalents. However, in doing so you move the zkEVM further away from EVM equivalence. This frustrates interoperability, making it harder for projects to migrate existing dapps over from Ethereum, as well as limiting the existing developer tooling available. Vitalik’s taxonomy classifies projects on this compatibility/performance scale. This ranges from type 1’s, which are the most compatible with Ethereum but are slow, to type 4’s which are the least compatible but the most performant.

Type 1 zkEVMs do not change any part of Ethereum regardless of the proving overhead. This makes them perfectly compatible, not just with the EVM, but with the entire Ethereum protocol. They also represent the best zkEVM developer experience, as type 1’s are compatible with all existing infrastructure and tooling from the Ethereum ecosystem. Developers can also port over smart contracts from Ethereum without making any changes. Furthermore, because this type of implementation is completely compatible with Ethereum, it could be incorporated into the core protocol in the future to improve performance.

The downside is that proof generation for a batch of transactions currently takes a very long time and requires a powerful machine. Community efforts are ongoing to optimize this through parallelization and dedicated ASIC hardware. 

This type of zkEVM is currently being worked on by the Ethereum Foundations Privacy and Scaling Explorations (PSE) team as well as Taiko. The latter is a project spun out of Loopring and at the time of writing they’re in alpha testnet stage with a mainnet launch planned for early 2024. 

Type 2 zkEVMs aim to be fully compatible with the EVM. However, they swap out a few zk-unfriendly components from the Ethereum core protocol. This approach significantly improves performance compared with type 1’s, whilst remaining compatible with the vast majority of existing Ethereum applications, infrastructure and tooling. However it does not solve many of the other complexities involved in proving the EVM itself, so speed is still relatively slow compared with type 3’s and 4’s.

Multiple projects including Polygon, Scroll and Consensys are all building zkEVM solutions that aim to be type 2 once completed. This type of solution offers a good balance between increased performance and developer experience.

The recently announced Immutable zkEVM is going to be implemented using Polygon’s open source zkEVM stack. ImmutableX currently operates on the StarkEx platform (built on Starknet), which offers application developers a limited set of common use cases, such as token swaps. ImmutableX will continue to operate on StarkEx alongside their new zkEVM. 

Immutable also plans to offer custom layer 3 zkEVMs to developers who wish to have more control over their own domain. Importantly, each layer 3 zkEVM will have access to a common liquidity layer. This is an important feature, as it solves the fractured liquidity issues experienced by many siloed scaling solutions today. This means that game assets can be interoperable across every layer 3 zkEVM deployed on the Immutable zkEVM. It also enables marketplaces to be built that aggregate NFTs from all layer 3 zkEVMs.

Polygon launched their own zkEVM mainnet beta on March 27th 2023. Consensys aims to launch their public testnet on March 28th, whilst Scroll’s mainnet launch is targeting the end of Q2. 

This type of zkEVM aims to be mostly EVM-equivalent but makes some tradeoffs to exact equivalence to further improve performance and simplify development. The aim here is to support most existing EVM applications and only require minimal rewriting for the rest. This type of zkEVM typically removes hard-to-prove precompiles, so if an application relies on these, it will require rewriting. 

According to Vitalik, projects don’t typically desire to be type 3. It is more of a starting point or transitory step towards becoming a type 2. 

This type of zkEVM works by taking smart contract source code written in a high-level language like Solidity and compiling it into a language specifically designed to be zk-friendly. This approach avoids much of the compute overhead by not having to zk-prove each part of the EVM execution trace. Once mature, this should enable a huge performance boost whilst making it easier to decentralize the network. Some would also argue that the flexibility of this approach is more future proof, as there is no guarantee that the EVM’s dominance will continue.  

However, there are some considerations one needs to be aware of. Any dapp that relies on predictable deployment addresses across different networks may not work ‘out of the box’. This is because the bytecode used to generate the contracts address will be different than on Ethereum. Furthermore, EVM debugging infrastructure may not work, as the resulting program execution does not use EVM bytecode. However, depending on what the high-level language compiles down to (e.g., LLVM), developers may be able to benefit from “traditional” debugging tools.

Starknet is actually considered a zkVM (note deliberate omission of the ‘E’), as it does not attempt to be EVM compatible. Smart contracts on Starknet are written in their own domain specific language (DSL) called Cairo. This language is designed from first principles to be zk-efficient, which massively reduces proving overhead. Starknet can be categorized as a type 4 zkEVM because of Warp, a Solidity to Cairo transpiler built by Nethermind. It allows solidity developers to deploy smart contracts on Starknet, whilst leveraging existing Ethereum developer tooling.ZkSync is another type 4 zkEVM. Like Starknet, they have a DSL called Zinc for writing provable programs, but they have opted to follow a Solidity-first approach, which they hope will allow the platform to benefit from the current network effects around the EVM. In this scenario, Solidity is first compiled to an intermediate language called Yul, then again to LLVM IR. Finally LLVM IR is compiled to zkEVM bytecode that developers can then deploy to zkSync. This modular design, with LLVM IR at the center, means that zkSync could support multiple languages in the future.

Like the Immutable zkEVM, both StarkNet and zkSync plan to introduce additional layers on top of their layer 2 platforms. These additional layers recursively checkpoint into the layer beneath them in the same way that the layer 2 rollup checkpoints to Ethereum. Starknet refers to this as fractal scaling and zkSync calls them HyperChains, but they are essentially the same thing. They allow near limitless scaling potential, as well as customizability and autonomy for different use cases.

Starknet mainnet alpha launched a while ago in November 2021 and thus has a flourishing ecosystem already. ZkSync Era (formally zkSync 2.0) launched their public mainnet alpha on March 24th 2023 and at the time of writing is already forming a strong ecosystem. 

Kakarot is an EVM written in Cairo and deployed on Starknet as a smart contract. This differentiates it from the other zkEVM solutions discussed so far, as there is no separate protocol involved. Kakarot’s developers have stated they are open to making this an independent layer 3 on top of Starknet, if it makes sense in the future. 

The contract contains an EVM bytecode interpreter that accepts incoming EVM transactions from users and translates them into a format understood by the StarknetOS. It also allows developers to deploy Solidity smart contracts to dedicated EVM storage within the contract. This solution also allows deployed solidity contracts to be fully composable with other Cairo contracts deployed to Starknet. 

The recent advancements in zk tech don’t stop at the EVM. There are some very talented builders working behind the scenes to build proving systems around the MoveVM.

Each zkEVM project is in various stages of development. However, one pattern that is common to all is the progressive transition from centralization to decentralization. 

Projects are incentivized to launch an MVP publicly as early as possible so an ecosystem of dapps can develop and drive network effects for the platform. However during this phase the tech stack is not fully mature. Therefore, it’s common to see projects implement a number of training wheels to use as fallbacks in the event of a system failure. These often include:

• Multisig governing of the layer 1 contracts to allow devs to quickly iterate and force outcomes in case a bug is detected in the code. This centralization vector could pose a security risk if that multisig account is ever compromised. 
• Enforced upgrade delays to give users and devs time to react to system change.
• Mechanisms for users to forcefully exit the rollup in case the centralized sequencer goes down or is compromised. At the time of writing this piece, only Polygon’s zkEVM has decentralized its sequencer using their Proof of Efficiency protocol. 

It is okay for a project to have such measures in place during its infancy, but there should be a clear strategy for removing these once the tech has matured. L2Beat does a great job of posting up-to-date information relating to a variety of risks founders should consider when picking a platform.

In addition to moving towards decentralization, it’s also a good sign if the zkEVM tech stack has been open sourced. This allows projects to coordinate bug bounty programs that incentivize hackers to test every line of code for weaknesses. The end result is more robust and resilient code. Every solution discussed in this piece has open-sourced most, if not all of their source code.

All of the solutions mentioned so far are in varying stages of development. As such it’s not prudent to compare transaction throughput at this stage. It’s also highly dependent on the complexity of smart contract executions, as well as network congestion. Depending on the implementation, estimates range from 2,000 TPS for a type 2 zkEVM all the way up to 20,000 TPS for zkPorter (the validium offering from zkSync that stores data on a separate data availability network). TPS is practically uncapped when fractal scaling (L3s, L4s, L5s …) is implemented.

However, current TPS is quite a different story. Starknet currently processes an average of 1.33 TPS. They expect to increase this significantly by implementing sequencer parallelization, as well as rewriting the sequencer and the Cairo-VM in Rust. ZkSync Lite processes 3.23 TPS on average and upon launch zkSync Era apparently processed ~40 TPS. Polygon have stated that upon launch, users can expect double digit throughput but that “the network and technology are too new to make any reckless predictions”. We could not find data for the other networks, however the point we’re trying to make is that there is still a lot of work to be done to allow these scaling solutions to reach their full potential. 

Zero-knowledge cryptography is at the very frontier of what is possible in Web3. It’s relatively new and has thus not yet been extensively battle-tested in production. It is also very complex, so bugs and vulnerabilities are likely to exist. The development teams know this and have all opted for a phased approach, gradually removing the training wheels over time. This allows them to quickly iterate and fix bugs as soon as they are discovered. There has also been competition around who can launch first on mainnet. This is not to say the dev teams have acted irresponsibly, but with speed comes additional risk. Users and developers should keep this in mind when considering how much they wish to risk in terms of capital, time or business. 

As of today, the EVM has significant network effects within Web3. This can be clearly be seen in number of EVM chains (e.g. BNB Chain, Avalanche etc…) as well as the proliferation of scaling solutions built around Ethereum. Zkrollups, and by extension zkEVMs, are the most secure scaling solution, as their state is managed by smart contracts on the Ethereum base-layer. They also have the least latency, as finality is reached as soon as the zkProof is verified on Ethereum. Ultimately, they have the potential to revolutionize Web3 gaming by making previously uneconomical use-cases more feasible. That being said, the tech is still in its infancy and has a long way to go before it reaches maturity. Both users and developers need to be aware of this and manage risk accordingly. 

There’s a reason why projects are competing to be the first functioning zkEVM on mainnet. Not only does it feed into crypto’s attention economy, but being first provides the best chance of  attracting builders and creating an early competitive moat. The tech is new and shiny right now, but as is also the case with layer 1 blockchains, zkEVMs will likely become commoditized over time. Prevalence of layer 3’s and core Ethereum upgrades like Danksharding will significantly enhance Ethereum’s scalability. This could result in innovation being pushed up to the application layer. The platforms that have built the strongest ecosystems of dapps with great content and solid network effects will have a huge advantage over the rest. 

In our opinion, what really matters in this quest is how projects maximize the developer experience. Regardless of the platform this will be critical to its broader adoption. AAA game developers are not going to care about the nuances of a zkEVM’s underlying circuitry, just like they don’t care about how AWS works vs Azure. If the solution is performant enough to meet their needs, has great support and good tooling then that’s what they’ll likely choose. 

That being said, different platforms today may be more attractive to certain types of builders. Starknet for example is undeniably the home of on-chain gaming at the moment. There is a dedicated community of developers and gamers working together to push that space forward. Builders wanting to participate in a community-driven ecosystem and tap into the composable infrastructure already built could start exploring here. On-chain gaming is a long way from becoming mainstream, and there’s a chance it remains a niche sub-genre indefinitely. However, the throughput required for on-chain games makes type 4 zkEVMs a good fit. We may see on-chain gaming expand in a meaningful way to zkSync Era, but it’s too early to tell. 

Developers wanting a more enterprise-like experience, who don’t want to put everything on-chain, would likely find a good fit with one of the company-driven type 2 zkEVMs, such as the Immutable and Polygon zkEVMs. Immutable for instance abstracts a lot of the blockchain complexity away from game developers by providing an SDK. This allows teams to focus on building great games rather than having to learn new languages and technologies.

Throughout the rest of this year and beyond we’re going to see rapid iterations and optimizations to these new scaling platforms. Many existing dapps will likely launch on zkEVMs just as they did with optimistic rollups. However, it will be more interesting to see what Web3 game developers do with the extra horsepower these platforms provide. As always BITKRAFT enjoy meeting and supporting talented founders. So if you are building something cool on one of these new platforms we’d love to speak to you.