Disclaimer: Taiko Protocol Design is still a work in progress. Below is its newest version, however, things might still change.

Taiko follows the “decentralized from day 1” approach. Below is the protocol description.

Taiko protocol consists of three stages: block proposal, validation, and proving.

TLDR:

• Taiko is a type-1 ZK-EVM, meaning it is Ethereum-equivalent. That is, it implements the Ethereum Yellow Paper specifications;

• The block execution is deterministic once the block is appended to the proposed block list. That is, all its properties are immutable from that point on;

• Both proposers and provers are permissionless. Anyone can start and stop running a proposing and proving node whenever they wish;

• Block metadata is validated when the block is proposed. The prover has no impact on how the block is executed and what the post-block state is;

• The proof can be generated after the block is checked for validity and its parent block’s state is known.

Anyone can run a Taiko proposer. The Taiko client (proposer) monitors the Taiko network mempool for signed and submitted transactions.

L2 tx fee = L2 EIP-1559* base fee + L1 tx fee + prover fee + proposer fee**

*By EIP-1559 fee, we mean that the L2 tx fee is split into (i) L2 network fee (base fee) and (ii) payment for the completed work (to provers, proposers, L1).
L2 EIP-1559 fee = L2 EIP-1559 tip (goes to the proposer) + L2 EIP-1559 base fee (goes to the Taiko DAO).

**Proposer’s work – including and ordering transactions into a block. To this end, the L2 fees (except for the L2 EIP-1559 base fee) are collected into proposer’s account on L2. L1 tx fee and prover fee are paid from their account on L1.
So, proposer fee = L2 EIP-1559 tip fee - L1 tx fee - prover fee. The proposer can lose money if the L2 EIP-1559 tip fees are insufficient for the L1 tx fee and prover fee.

Once a proposer has collected enough transactions, presumably including and ordering them with the intent to generate a (maximum) profit, they create a block. Profit means that for the proposer, the sum of transaction fees (L2 tx fees) from the block is larger than L1 tx fee + prover fee + EIP-1559 base fee.

Proposer determines the transaction sequence in the block. When a block is built, the proposer submits a proposeBlock transaction (block = transaction list + metadata) directly to Ethereum through the TaikoL1 contract. There is no consensus among L2 nodes, but there is some networking between L2 nodes (syncing, sharing transactions, etc.) However, the order of Taiko blocks on Ethereum (L1) is determined by the Ethereum node.

All other proposers can also monitor the L2 transaction mempool and identify proposed Taiko blocks in pending L2 proposeBlock transactions.

Many blocks are proposed in parallel and become pending in the Ethereum mempool. However, Taiko supports only a constrained amount of slots (say 10,240) for unverified blocks (both proposed but not proven and proven but not verified) on Ethereum’s Execution Layer and reuses them to minimize the block proposing fee.

The block execution is deterministic. When the block is proposed, the block data is published on Ethereum, and the block is appended to the proposed block list stored in the TaikoL1 contract. After that, all block properties are immutable.

All Taiko nodes connect to Ethereum nodes and subscribe to Ethereum's block events. When a Taiko block proposal is confirmed, the block is appended to a queue on L1 in a TaikoL1 contract. Taiko nodes can then download these blocks and execute valid transactions in each block. Taiko nodes track which L2 blocks are verified by subscribing to another TaikoL1 event on Ethereum.

The block consists of a transaction list (txList) and metadata. The txList of an L2 block will eventually (when EIP-4844 is live) be part of a blob in the L1 Consensus Layer (CL). However, txList is not directly accessible to L1 contracts. Therefore, a ZKP shall prove that the chosen txList is a slice of the given blob data.

A block is supposed to be valid if it meets several criteria:

• Has a byte size smaller than K_maxBobSize (also enforced in contracts);

• Can be RLP-decoded into a list of transactions without trailing space;

• Contains no more transactions (valid and invalid) than the protocol constant K_BlockMaxTxs;

• Has a total gas limit for all valid transactions not exceeding the protocol constant K_BlockMaxGasLimit plus config.anchorTxGasLimit.

Once the block is proposed, the Taiko client checks if the block is decoded into a list of transactions; if the txList is not decodable, then the block is an empty block with only an anchoring tx.

The Taiko client validates each enclosed transaction and generates a tracelog for each transaction for the prover to use as witness data. If a tx is invalid, it will be dropped.

A transaction is supposed to be invalid if:

• Has an invalid transaction signature;

• Has an invalid transaction nonce (different from the sender account's current nonce);

• The account does not have enough ETH to pay for eth_value + tx_gaslimit * tx_gas_price;

• Has some contract code deployed on the sender account (EIP-3607);

• Has a gas limit smaller than the intrinsic gas, g0, used by the transaction.

• The first transaction in the Taiko L2 block is always an anchoring transaction.

The anchoring transaction contains some extra data not directly available by the ZK-EVM itself.

A ZK-EVM covers

• Transaction proof for each transaction (same as in Ethereum);

• State Proof == MPT state trie (full proof of all the state updates in the block);

• Execution Proof == EVM bytecode (given the right inputs, one will get the right outputs).

So, the anchoring transaction verifies

• the 256 hashes of the latest blocks (that are not a part of Merkle Tree);

• L2’s chain ID and EIP-1559 base fee.

The block can be proven as soon as

1. All enclosed valid transactions in this block have been executed (necessary execution trace for computing ZKP was generated);

2. Its parent block’s state is known.

Proof proves a transition from the parent block state to the new block state.

The block is verified when

1. Its parent block is verified;

2. There is a valid ZKP that proves the transition from the parent state to the current block’s state.

Anyone can run a prover.

As the block execution is deterministic, all Taiko clients can calculate the post-block state. And no one knows more about the latest state than anyone else. Furthermore, for L2 users, the transaction is confirmed once the block is proposed. That is, no need to wait for ZKPs.

Provers can submit proofs for any block they like. Multiple provers may work in parallel to generate ZKPs for one or multiple Taiko blocks, but only the first proof will be accepted for any given block transition (fork choice). The address receiving the reward is coupled with the proof, preventing it from being stolen by other provers.

To ensure that all user assets are secure and all block transactions are valid even if there are bugs in the proof generation, Taiko protocol for the time being introduces an oracle prover.

The oracle prover checks all state transitions (by running a node to run over all transactions in the block) and may override existing state transitions (fork choices) that regular provers have proved. The cool-down window is 5 minutes (timing planned for next testnet).

Imagine the parent block hash A. Then, the new block’s hash should be B. And a fork choice should be A → B. But if there is a bug in the proving system, it may be possible to generate a valid proof for A → C.

In this case, the oracle prover sees that A→ C is incorrect and reports to the protocol that A should transition to B, not C. Then a regular prover generates a new proof for A → B.

Note: the oracle prover cannot prove/verify blocks directly and thus cannot change the chain state. Therefore, a real ZKP is still required to prove the overridden fork choice.

Explore open positions on our job board.

To stay updated on the latest from Taiko:

• Website: https://taiko.xyz

• Discord: https://discord.gg/taikoxyz

• GitHub: https://github.com/taikoxyz

• Twitter: https://twitter.com/taikoxyz

Contribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the contributing guide.