<aside> đź‘Ś This doc focuses primarily on zkRollups / zkEVM (vs. other applications of ZK). We cover how these work, who are the leading companies building in the space, investment theses, and what the future might look like. This was written in early Aug 2022.
</aside>
<aside> 🔑 Before we start, it’s important to understand transactions have three fundamental parts (or layers) to them:
</aside>
Q1: What’s a rollup?
A rollup is the act of aggregating (or “rolling up”) multiple transactions on a L2 (Layer 2) and then settling that batch of transactions in a single transaction on a L1 chain (e.g. ETH). Rollups provide faster and cheaper transactions for users by moving the data availability and execution layers off-chain, and only utilizing data availability and consensus on the L1 to settle batches of data at once. Today, there are two main categories of roll-ups: optimistic and ZK (zero knowledge).
Q2: What’s the difference between optimistic and ZK rollups? Is one better?
Optimistic roll-ups assume every transaction is valid and rely on incentives & game theory to discover invalid ones. Verifiers can submit a “fraud proof” if they discover a discrepancy after re-executing all transactions, which is followed by a potentially lengthy challenge process that can result in slashing penalties. While optimistic roll-ups are a step in the right direction, they still require 1) the L1 to re-execute all computations which doesn’t optimize gas savings, and 2) can take much longer to fully settle on L1 (e.g. hours/days) in case of challenges.
ZK roll-ups send the batch of transactions to an off-chain prover which generates a cryptographic proof to demonstrate the transactions are valid from the jump. A smart contract on L1 can verify the proof easily without re-executing the computation (only the diffs in state are posted to L1 vs. all tx data), which saves an order of magnitude on gas fees ($$ → cents), transaction speed (2000 TPS vs. 14 TPS on L1) and avoids any challenge processes which makes it quick & simple to provide frictionless transfers between L1 and L2.
Q3: ZK rollups sound much better - why isn’t it the de-facto winner?
Because existing ZK-rollup solutions (zksync 1.0, Starkware) are filled with friction for builders. They require expressing your code in its pure mathematical representation (which are used to create ZK circuits), which has historically been hard to do for Turing complete functionality including loops, recursion, generating signatures etc. Zksync 1.0 attempts to solve this via a compiler that converts your code into something “ZK-able”. However, it only supports a limited set of actions (e.g. payment/swaps/NFT transfers), vs. general-purpose smart contracts. Starkware, on the other hand, requires developers to re-write their implementation in its own language (Cairo), which adds substantial overhead to ongoing development.
Q4: What’s a zkEVM and why all the recent noise?
zkEVMs finally allow developers to avoid the pain referenced in Q3 above by supporting any generic Solidity code to support ZKrollups out of the box. This was thought to be years away as little as a year ago, as making the entire EVM “ZK-able” was technically challenging and computationally expensive (would take hours creating a proof). However, recent advancements in hardware (ASICs), approach (specialized circuits for heavy computational functions such as hashes, similar to how the GPU was created to complement the CPU by handling graphics computations), and parallelization (breaking up programs into smaller circuits and executing them in parallel) have fast-forwarded this to be near-production now!
Q5: What zkEVMs are available today? There have been three recent zkEVM announcements over the past couple weeks: Matter Labs with zkSync 2.0, Scroll, and Polygon (all available or soon to be available on TestNet). zkSync 2.0 has launched a zkEVM compatible with EVM, whereas Scroll and Polygon have created their zkEVM implementations to be equivalent to EVMs.
Q6: What’s the difference between EVM compatibility and equivalence?
At a high level, zkEVMs which have EVM compatibility can execute your Solidity source code by compiling it in a way that runs within the zkEVM. zkEVMs which have EVM equivalence natively execute your Solidity source code as is (no compilation/conversion required). To use an analogy, EVM compatibility means visiting a foreign country with a really good translator, whereas equivalence means you natively speak the language.
While EVM compatibility can support multiple input programming languages (Go, Rust, etc) and support non-native concepts (e.g. account abstraction), being EVM equivalent is inherently more robust and developer friendly within the Ethereum ecosystem b/c it provides strong assurances that their code behavior will work as designed. EVM equivalence maintains the promise of composability across DeFi and other dApps, which is critical to the growth of the ecosystem. Although EVM-compatible zkEVMs promise to work in 99+% of use cases and require little-to-no code/contract changes, it’s not fully guaranteed — from my personal experience working with compilers who’ve promised similar things, its often the case developers will have to modify or even re-implement some parts of their code. Further, equivalent zkEVMs support native Ethereum dev tooling (JSON-RPC, HardHat plug-ins, etc) and enable L2s to adopt the EIPs they desire with guarantees they’ll work when launched on L1 mainnet — all out of the box.
<aside> 🔑 Takeaway: While EVM compatible solutions may offer developers added flexibility, this is outweighed by EVM equivalent solutions which ride the network effects of ongoing Ethereum updates and the broader ecosystem.
</aside>
Q7: Which zkEVMs are compatible vs. equivalent? Matter Labs (zkSync2.0) launched a compatible zkEVM on TestNet whereas Scroll and Polygon will soon launch zkEVMs (on TestNet) which are EVM-equivalent.