### Taiko ZK-EVM: Layer 2 Finality Brecht Devos \ <brecht@taiko.xyz> --- ### Taiko - 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 --- ### Taiko - 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 --- ### Taiko 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 --- ### Taiko Protocol  - 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) --- ### Taiko - 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 --- ### Taiko > 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 (*) --- ### Taiko  --- ### Taiko 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 --- ### Taiko - 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 --- ### Thanks!  Taiko - Website: <http://taiko.xyz> - GitHub: <http://github.com/taikoxyz> - Twitter: <http://twitter.com/taikoxyz> <style> .reveal { font-size: 24px; } </style>