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