zkEVMs
tl; dr
- with zk proofs, zk-rollup can achieve better scalability, security, and faster finality as a scaling solution for ethereum.
- zk-evms are a scaling solution compatible with ethereum. other solutions such as zksync lite, loopring, and starknet were not evm-compatible.
- example: the bundling of txs happening within a certain period and settling the proof of a block of txs on the ethereum network instead of the full list of tx that may congest the network.
- "they use zk-snark technology to make cryptographic proofs of execution of ethereum-like txs, either to make it much easier to verify the Ethereum chain itself or to build ZK-rollups that are (close to) equivalent to what Ethereum provides but are much more scalable." - vub
design challenges
- evm has limited support of elliptic curves, hard to do proof recursion since cyclic elliptic curve is not directly supported.
- evm word size is 256bit, and zkp work over prime fields. mismatch field arithmetic inside a circuit requires range proofs, which adds many constraints per evm step (blowing up the the circuit size).
- evm has many special opcodes, bringing challenges to circuit design.
- evm is a stack-based vm. zksync and starkware architectures define their own ir/air in the register-based model (language compatible instead of native evm-compatible).
- ethereum storage layout carries large overhead, relying on keccak and mpt (both not zk-friendly).
- machine-based proof has a large overhead (how to complete an evm circuit?).
recent advancements
- usage of polynomial commitment, lifting constraints to any degree with a universal or transparent setup.
- lookup table arguments and customized gadgets, optimizing zk-unfriendly primitives (bitwise operations).
- recursive proof is more feasible. this type of proof has a large overhead as it relies on special pairing-friendly cyclic elliptic curves (mnt). halo can avoid the need for a pairing-friendly curve and amortize the cost of recursion using special inner product argument.
- hardware acceleration, making proving more efficient.
types
- type 1, fully ethereum equivalent. example: taiko and the community zkevm by pse.
- type 2, fully evm equivalent: might differ on data structure and state trees. example: scroll and polygon hermez.
- type 2.5, evm-equivalent, except for gas costs (increased).
- type 3, almost evm-equivalent.
- type 4, high-level-language equivalent (compatible with smart contract languages). example: zksync.
