Taiko ZK-EVM: Layer 2 Finality

Officially started in Q1 2022
I started contributing to the EF PSE ZK-EVM effort in Q3 2021
Several teammates came from Loopring
- Split because Loopring is an app-specific ZKR, while Taiko is general purpose
Around 20 people now

Type 1 ZK-EVM
- Prioritize Ethereum equivalence, give up ZK-friendly optimizations
- Main benefit is smooth migration and reusability of all L1 dapps, tools, and infrastructure
- Main downside is slower proof generation
Decentralized
- Only relies on Ethereum public data, anyone can run a node
Permissionless
- Any proposer or prover can participate
Architecture
- ZK-EVM (community effort from PSE ZK-EVM circuits)
- L2 node
- Protocol

Block proposers
- Submit a list of transactions to the rollup contract
- Ordered by Ethereum validators
- L2 block parameters are added by the smart contract (timestamp, difficulty)
- This “block” is appended to the chain
This means that => block execution is deterministic after the block is proposed
- Blocks are never reverted (the protocol has rules to skip over invalid data)
- Instant finality
- Parallel proof generation

Block provers
- Generate proofs for blocks
- All data necessary to generate the proof is on-chain
- Blocks can be proven in parallel
We call a block verified when the block and all its parent blocks are proven
- Block pre and post state known by smart contracts at this point
- Important for bridging (L2 -> Lx)

Finality achieved immediately after the block is proposed
Verified status achieved after the block, and its predecessors, are proven
- Smart contracts depend on ZKPs to efficiently execute the transactions
- For verified blocks the correct pre and post states are known
- Other smart contracts can then use this to read any state on L2
- L2 -> Lx bridging delay is ~ the proof generation time

L2 -> Lx bridging delay is ~ the proof generation time

It would be possible to do better in some cases:
- If we know the state at some point
- And somehow it can be shown that some state hasn’t been changed for some time
- And we can prove this significantly faster than just generating a full ZK-EVM proof
ETH balance of an account a good simple match for this
- ETH spent from an EOA visible from the transaction itself, no need to actually proof the execution (*)

This is nice because:

Can speed up withdrawals in a lot of cases
No or simple ZKP circuits required (attractive for optimistic rollups)
ETH in a state where it is directly usable on L2 and L1/other L2s
System should be expandable for more general cases than just ETH
Can be implemented completely in bridge smart contracts
- At block proposal time we may already want to have a ZKP for things like signature compression, so may make sense to just do the optimized data format there as well

Proof generation times even less important with this
- For most transactions verification doesn’t matter, mostly only bridging transactions
- The general case is pretty fast already (depends on max L2 block size)
- For fungible tokens liquidity providers can also be used trustlessly for instant withdrawals
This means that => proof generation times are really only important for cost
And proof generation times will only go down from here
- More efficient proof generation systems: HyperPlonk, Caulk, etc.
- General prover optimizations and tricks

Taiko