The Battle of zkEVMs
An overview of the landscape ahead of mainnet launch for Polygon and zkSync
This post will cover:
Introduction
ZK proofs and ZK rollups
EVM and zkEVM
The ZK dilemma
Overview of zkEVM projects
Role of tokens in zkEVMs
Frameworks to think about Polygon vs zkSync adoption
Related topics: data availability, L3 hyper-networks and decentralisation of rollups
Concluding thoughts
Introduction
Ethereum’s scaling issues became really evident over the last cycle. Restricted blockspace led to high fees, which excluded newer entrants from using the chain and prioritised higher-value applications such as DeFi.
While there are many different scaling solutions (both on-chain and off-chain), Ethereum adopted a rollup-centric roadmap back in 2020. Simply speaking, rollups take a bunch of transactions, compile them into a batch and execute them off-chain. The results are posted to Ethereum for settlement along with the transaction data, which allows for verifying the correctness. This is computationally less intense and reduces the data posted on Ethereum, resulting in higher throughput and lower fees. Layer 2 scaling solutions gained popularity throughout 2022 and we’ve seen a rapid increase in both TVL (in ETH terms) as well as funding.
Rollups come in two forms - optimistic and zero knowledge. The main difference between the two is how transactions become final:
Optimistic rollups assume that off-chain transactions are valid unless otherwise proven (“optimistic”). Anyone can challenge the submitted state through fraud proofs, whereby batches are verified using the relevant transaction data. The challenge period is ~1-2 weeks. This delays finality, which mainly affects the withdrawal period. It’s not an issue for small users since liquidity providers can bridge the gap. However, large users and active traders can’t get around it and suffer from capital inefficiency.
Zero-knowledge (ZK) rollups make use of cryptographic validity proofs, allowing the Ethereum network to verify that a batch of off-chain transactions was correctly executed. In other words, ZK rollups rely on math rather than game theory. Finality is reached within a few minutes, once the proof is verified and accepted on Ethereum. ZK rollups are preferred over Optimistic rollups both for faster finality and requiring less data to be posted on-chain for verification (lower fees).
Despite the advantages of ZK rollups, the space is dominated by Optimistic rollups. Arbitrum and Optimism alone control a combined 83% of all value locked. The main reason for this is that the ZK technology is less mature and more difficult to implement as a general-purpose rollup that is also compatible with the EVM and existing solutions on Ethereum.
This might change soon with Polygon and zkSync leading the way. Polygon has committed to deploy their zkEVM to mainnet on the 27th of March, while zkSync is already live for developers, but not yet for users (expected by the end of March).
Being first out the door can bring significant first-mover advantages and enable a strong position in the market. To learn about the nuances between the different approaches and what each one brings to the table, we first need to cover some basics.
Zero-knowledge proofs and ZK rollups
Zero-knowledge proofs (ZKP) are used to prove with certainty that one party (the prover) knows something, without revealing any information about the actual inputs to the other party (the verifier). ZKPs can for example be used to prove a calculation was performed correctly without revealing anything about the calculation, or proving the validity of a transaction without revealing any details of the transaction. Good introductory explainer on ZKP here.
ZKP are useful for privacy, but can also be used in rollups to verify that transactions were performed correctly. Ethereum can take the proof posted by the rollup, verify it and be certain that off-chain transactions were executed correctly without having to re-calculate any of the transactions. This allows for scaling with almost instant finality.
While ZK rollups aren’t a new idea per se, early implementations have had limited functionality such as simple token swaps or payments. Existing solutions are either for a specific use-case (zkSync Lite), app-specific (dYdX) or general purpose, but with limited support for Solidity and Ethereum tooling (Starkware). zkEVM is an extension to these and supports existing EVM tooling and developer solutions (libraries, wallets, marketplaces…). This allows for easy migration of existing Ethereum contracts and developers to the rollup.
EVM and zkEVM
The Ethereum virtual machine (EVM) can be described as a computer run by a network of computers. It functions as the execution environment for running smart contracts on Ethereum. Developers create smart contracts in Solidity, which the EVM executes and computes state changes (such as the balance in each wallet at a specific point in time).
zkEVM is a virtual machine that executes Ethereum smart contracts in a way that’s compatible with zero-knowledge proofs (both EVM and ZKP-friendly). It improves on current ZK rollups by allowing existing dApps on Ethereum to deploy on the zkEVM with limited/no modifications to their code. Existing developer tooling is also supported. This reduces friction for both users and developers, as they don’t have to reinvent the wheel or maintain multiple code bases.
The ZK dilemma
The challenge with creating a general-purpose zkEVM is that the EVM was not designed for computation of ZK proofs (more about design challenges here). Therefore, the earlier in the stack you abandon the EVM, the more you can optimise it for ZK computation which increases performance.
The ZK dilemma represents the tradeoff between performance and compatibility. Higher optimisation for ZK computation leads to less EVM compatibility. Being more EVM-equivalent is better for usability and developer friendliness, but it reduces performance and proof generation is slower. One is not necessarily better than the other, but teams have had to make design choices on what to optimise for.
This dilemma was formalised in a blog post by Vitalik, where he suggested a framework on how to categorise EVM compatibility and think about the zkEVMs being built by different teams. The main parameter for categorisation is how close a given zkEVM is to Ethereum itself. Type 1 is closest (fully Ethereum Equivalent), while type 4 is furthest away (EVM compatible).
Of the four frameworks laid above, most teams have chosen either type 2 (EVM equivalent) or type 4 (EVM compatible) as their approach:
EVM equivalence = Looks and feels like Ethereum from a developer and user point of view, but has some differences in data structures. Protocols can directly copy-paste their code and use existing developer tooling.
EVM compatibility = Can execute smart contracts written in Solidity or other high-level languages by using a compiler. This means most applications are compatible, but some developer tooling might require modifications. For example, low-level debuggers can’t generally be carried over (bytecode level).
Overview of zkEVM projects
The number of teams building zkEVMs has grown to tens, if not hundreds depending on which source you trust. Being first out the door matters, as it can bring significant first-mover advantages and generate a wide moat. Therefore, zkSync and Polygon are of most interest at this point in time.
Polygon will launch a mainnet on the 27th of March
zkSync launched its mainnet for developers on the 16th of February and is expected to open up to users 4-6 weeks after that (by the end of March!)
Scroll and Consensys are slightly newer entrants and both in closed testnet as of now
StarkNet deserves a mention for being the first general-purpose ZK rollup. They’ve made design choices that make the experience less smooth for developers, such as using Cairo programming language. However, Nethermind has been developing a transpiler to transform code in Solidity to Cairo (Warp), which essentially makes Starknet EVM compatible (Type 4).
Polygon zkEVM:
Polygon zkEVM will be the first EVM-equivalent ZK-rollup when it launches on mainnet on March 27th. It’s fully compatible with existing solutions on Ethereum and has passed 100% of the Ethereum test vectors. Smart contracts and code can be directly copied over and easily deployed. Polygon’s zkEVM has also passed two public third-party audits, in addition to having been open-source for ~6 months which allows scrutiny from the community and peers.
Main components and features of Polygon’s zkEVM include:
Proof of Efficiency (PoE) smart contract, which ensures that state transitions are done correctly. The role of batch creation is split between two different parties:
Sequencers propose transaction batches to the network: They receive transactions from users, bundle them up into a batch and propose it to the PoE smart contract as valid L2 transactions. Sequencers pay L1 transaction fees to Ethereum, plus deposit a fee in $MATIC as incentive for Aggregator to include the batch in the validity proof. In exchange, the chosen proposer is rewarded with transaction fees from users if the batch is deemed valid.
Aggregators confirm batches are valid and provide validity proofs: Receive all transaction data from Sequencer, along with the proposed batch. The Aggregator interacts with the zkProver, which generates a small ZK proof through complex polynomial computations. Aggregators compete against each other, as the right to create the validity proof is earned by being the first Aggregator to do it. In exchange, they are compensated with the $MATIC that Sequencers deposit. This incentivises the efficiency of aggregators, which should lead to a shorter prover time and faster finality.
Both roles are completely permissionless, meaning anyone can be a Sequencer or Aggregator.
The Sequencer is profitable if L2 tx fees > L1 call + Batch Fees (in $MATIC). The Aggregator is profitable if Aggregation reward (in $MATIC) > L1 call + Server cost.
Synchroniser is part of the zkNode architecture and enables synchronisation of batches and their validity proofs. Happens after both have been added to the L1. The synchronizer is in charge of getting all the data from smart contracts, including transactions posted by sequencers and validity proofs posted by validators. This data is stored in a large database that third parties can interact with through JSON-RPC.
zkProver is where the actual validity proofs are created. Every aggregator will use it to validate batches and provide validity proofs. In Polygon’s case, it’s intended to run on any server and aims to be compatible with most consumer hardware. However, since the right to create validity proofs goes to the fastest aggregator, it’s likely only specialised node operators will be competitive. The zkProver contains both a STARK and a SNARK builder. STARK proofs are bigger than SNARKs, so the SNARK-builder is effectively used to prove the correctness of the STARK proof. This way, it becomes cheaper to verify the proof on L1 since the end result is significantly smaller in size (helps in reducing the gas costs from 5M to 350K).
Source: Polygon
The LX-to-LY bridge enables users to bridge funds to the rollup through a decentralised bridge. It’s a combination of two identical smart contracts except where they are deployed. The L1 contract is deployed on the Ethereum mainnet and the L2 contract is on the specific rollup.
zkSync Era:
zkSync Era is the first EVM-compatible ZK rollup to launch on mainnet. It entered Fair Onboarding Alpha on the 16th of February, allowing registered projects to deploy on mainnet and start testing. Users will have to wait for the next step Full Launch Alpha before getting to use the mainnet (expected 4-6 weeks after Fair Onboarding, so by end of March). Similar to Polygon, zkSync Era takes security seriously and has gone through an external audit (OpenZeppelin) with another one scheduled. zkSync Era is now also open-source under MIT/Apache 2.0 licence, which allows for peer review and public scrutiny.
A more extensive overview by Louround can be found here, but main components and features include:
The operator carries out all essential ZK rollup functions. They compile transactions, produce blocks, create the cryptographic proof (SNARK) and submit data to the main Ethereum chain for verification. In addition to the proof, a small amount of data for every transaction (the state ∆) is published over the main-chain network as cheap call data. This enables anyone to reconstruct the state at any moment. The proof and the state ∆ are verified by the smart contract, thus verifying both the validity of all the transactions included in the block and the block data availability. A key difference to Polygon’s approach is that the sequencer and validator are not separate functions in zkSync Era. While the validator doesn’t have the power to do anything with users’ assets without explicit authorisation, it’s still a risk vector. There are plans to decentralise the process by splitting the responsibility between Validators and Guardians, which would make the system less reliant on a single operator (risk of outages etc) and increase censorship resistance.
Yul and LLVM compilers: zkSync uses compilers to transform Solidity into a custom, circuit-compatible bytecode designed for their zkEVM. This increases performance, while still enabling existing Ethereum-based dApps to deploy with minimal/no changes on zkSync Era. Developer tooling such as wallets and other infrastructure is also supported, but not for example debuggers. LLVM-based compilers have become industry standards due to their robustness and efficiency after decades of battle-testing.
Native Account Abstraction: Ethereum has two types of accounts - Externally owned accounts (EOA, controlled by anyone with the private key) and Contract accounts (smart contracts deployed to the network, controlled by code). For some use cases this difference can create a lot of friction (smart-contract wallets, privacy protocols…). Thanks to native account abstraction (AA), accounts in zkSync Era can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract. Having AA integrated into zkSync supports the execution of multiple calls or using smart-contract wallets (like Argent) straight out of the box.
zkPorter is one of the largest and most important features of zkSync Era. It’s a data availability (DA) layer connected to the zkEVM. Users can choose to have DA either with Ethereum for maximum security, or zkPorter for cheaper TX at the expense of some security. The data remains available on zkPorter using a PoS mechanism backed by stakers of the native token $ZKS. Therefore, zkPorter relies on Ethereum for transaction validity and on stakers of $ZKS for data availability.
zkPorter gives 10x the performance compared to the zkRollup Both parts of the ZK rollup will remain interoperable with each other. This means that contracts and accounts on ZK rollup will be able to seamlessly interact with accounts on the zkPorter side and vice versa. From a user’s perspective, the only visible difference will be significantly lower fees if using zkPorter (estimated <$0.0001).
The role of tokens in zkEVMs
Different teams are taking slightly different approaches to token utility. Transaction fees are paid in ETH across most zkEVMs, which makes the user experience similar to interacting on Ethereum except that it’s significantly cheaper. This is in contrast to StarkNet which requires users to pay transactions with their native token. Below is all we know so far about the different approaches and token launches:
Polygon uses $MATIC to enable the auction market between Sequencers and Aggregators. Users pay L2 transaction fees in $ETH, but Sequencers deposit $MATIC to get their batch included by the Validator.
zkSync has confirmed that a native token is coming and dropped hints about an airdrop in interviews. Matterlabs, the company behind zkSync, has raised a total of $458m. So far we know that ⅓ of the token supply goes to investors (per the latest funding round), with the remaining ⅔ to the community. The native token is not used anywhere in the zkEVM, but it will be used for L2 governance and zkPorter (the data-availability solution). Holders of the token can become guardian nodes by staking their position and agreeing to provide data. Therefore, the token should be released ahead of launching zkPorter.
Scroll is earlier in the lifecycle than Polygon and zkSync and currently in pre-alpha testnet (only whitelisted users allowed). The team has hinted about a token in Discord, but not much more information has been released.
Consensys has similarly released an invite-only testnet, but no indication of a native token or what its role would be.
Frameworks to think about Polygon vs zkSync adoption
Polygon and zkSync are planning to launch approximately at the same time, and it will be interesting to follow their adoption. Below are a few ways to think about who will take the lead:
Strength of business development (BD): Polygon’s BD is arguably the strongest in the space and most real-world businesses are choosing Polygon as their partner to enter the space. This includes Reddit-NFTs, Stripe payments, the Starbucks loyalty program and other big-hit names (Instagram, Adidas…). zkSync is a new entrant and seems more focused on dApps/crypto-native applications for now. However, zkSync has secured >175 launch partners (including Uniswap, Aave and Curve), which means there will be a healthy ecosystem of dApps to use directly from the get-go. In addition, there are another 150 of dApps in stealth mode (startups that are yet to launch), some of which will launch first on zkSync. Worth keeping an eye out for these!
The case for optimising for usability: EVM-equivalence allows leveraging the Ethereum ecosystem and its network effects. While this comes at a cost of performance, Polygon bets on having enough performance at maximum usability. Ethereum has the largest developer base and making their lives as easy as possible is a big advantage. While the EVM-compatible path means that most applications and tooling work without modifications, humans tend to follow the path of least resistance. Another consideration is minimising the surface area for bugs and errors. The more modification it requires to deploy on the rollup, the higher the risk of mistakes.
The case for optimising for performance: Cheaper transaction costs can unlock entire new use cases. While the nominal difference between transaction costs of $0.1 and $0.01 is small, it’s significant from the perspective of the opportunities it can unlock when transaction costs get down to fractions of a cent. A 10x improvement in cost can lead to a 100x improvement in adoption through new use cases. Enabling higher performance is also making the rollup more future-proof, as we are still far from mass adoption and millions of transactions.
Ecosystem funds: In combination with the latest raise, zkSync also raised a 200m ecosystem fund from BitDAO to create zkDAO. These funds are earmarked for funding projects building and launching on top of zkSync. This will likely be a major boost for the zkSync ecosystem and attract developers. Polygon hasn’t committed to any specific number for supporting the adoption of the zkEVM, but we know the foundation has deep pockets exemplified through multiple large acquisitions and allocating $1bn towards ZK development back in 2021.
Airdrop farming: It’s plausible that airdrop rumours induce some amount of action on zkSync, similar to what we’ve seen across the Arbitrum and Optimism ecosystems. While part of the transaction volume is inorganic (not real demand), it does lead to stress-testing of the system and looks good on adoption-related metrics. This in turn can attract more developers and get the flywheel spinning. Polygon doesn’t have this advantage, as the MATIC token already exists.
Building for current vs future EVM: While EVM equivalence is trying to make the experience as smooth as possible for the current stack, it kind of makes the assumption that EVM won’t change or evolve. Building towards a potential future is a risk though since that future might not materialise.
Related topics:
Data availability: While ZK rollups are cheaper than Optimistic rollups due to less data being posted on-chain, they don’t solve the data availability problem. Data availability is a key cost for rollups, which is why transaction costs for optimistic rollups can be tens of cents despite minimal computation overhead. Alex Gluchowski from zkSync argues that costs for ZK rollups will also primarily be determined by the cost of data availability, rather than the prover-cost which is more often the focus of discussion. Hence, there should be more focus on reducing the amount of data posted on Ethereum. Whether this holds true will become clearer once we start seeing real usage on the mainnet and can compare stats across zkEVMs, but it’s evident that data availability will play a part in the future. The teams building zkEVMs are taking different approaches on this front. zkSync is developing zkPorter to be an (optional) integrated part of the rollup. Polygon is developing Avail (specialised data-availability blockchain) separately, but it could be integrated with the zkEVM in the future. There are also other external solutions, such as EigenDA (built on EigenLayer) or Celestia that could fill this gap.
L3 hyper-network - one prover to rule them all: Layer 3 typically refers to app-specific chains for maximum customizability. For example, teams building on L3 could choose between different data availability solutions, tokenomics/aligning incentives and level of privacy. The benefit of ZK rollups is that you can create a network of L3 chains that all communicate with each other through native bridges secured by zero-knowledge proofs. Given that $2.5bn was lost through bridge hacks in 2022 alone, it’s a clear problem. However, the vision of L3 hyper networks requires everyone to use the same prover. The question is no longer “which rollup will dominate?”, but rather “which prover will be the one that everyone uses?”. Is this problematic? Depends on your beliefs when it comes to decentralisation and open competition.
Decentralisation of rollups: There are different interpretations of what decentralisation actually means in terms of rollups. Patrick McCorry notes that rollups rely on 1 honest party and a trusted third party (bridge smart contract), rather than honest majority. Taiko (building Type 1 zkEVM) proposes an alternative framing: “A decentralised rollup is one where any user can be sure that their transaction will be executed”. This goes one step further from just enabling users to force a transaction on the L1 smart contract and get their money out of the rollup.
Since most users are uninterested in running a full node or the prover add-on for ZK rollups, the level of decentralisation depends on the diversity of participants that perform necessary functions (such as sequencer or validator). Therefore, allowing new participants to enter any of these functions in a permissionless way is crucial. While decentralisation leads to less censorship resistance, it can lead to less efficiency through wasted effort/work and add complexity. Therefore, it seems more reasonable to expect teams to move towards more decentralised models as they mature, rather than being decentralised from day 1. Also worth keeping in mind that decentralisation is a scale rather than a binary feature, and comes with tradeoffs.
Looking at the solutions different teams are building, it seems that decentralisation plays a bigger role the closer to Ethereum equivalence (Type 1, such as Taiko). It’s reflected both in their ethos and design choices (permissionless and decentralised prover and proposer set).
Concluding thoughts
This post ended up becoming longer than initially intended. Decided to focus on Polygon and zkSync since they are both deploying on mainnet in about a month’s time, and hence more relevant. Throughout the process of writing, I’ve gained even more respect for the teams building zkEVMs (or ZK rollups more generally) than I had before. The pace of innovation has been impressive.
An encouraging sign is that so many of the teams have chosen to open-source their code. This resonates with the collaborative and open nature of crypto. You can claim to be this or that, but at the end of the day, actions speak louder than words!