Proposing Taiko blocks

On Taiko, the next L2 state is known immediately and deterministically at the time a block is proposed to the TaikoL1 contract. After a block is proposed, a series of checks are done to compute this post-L2 state:

1. Block is proposed by any proposer (permissionlessly).
2. Block level properties' validity is checked by the TaikoL1 contract with the (proposed block intrinsic validity function).
3. Proposed block is downloaded by a Taiko node, and the transaction list is parsed over and checked for validity (transaction list intrinsic validity function).
   • IF every transaction in the list is valid, an ordered subset of the list is created by skipping over transactions which have an invalid nonce or the sender has too little Ether balance to pay for the transaction. This ordered subset is used along with the anchor transaction to create a Taiko L2 block.
   • IF any transaction in the list is invalid, an empty block (with only the anchor tx) is created on L2.

Building the blocks

The Ethereum yellow paper has well-defined rules to compute the state transition. We use these same rules to take a proposed block, and compute the post-block state on Taiko. The high level overview of creating L2 blocks as follows:

1. The system starts by creating a new L2 block with an anchor transaction. This anchor transaction is always the first transaction in the block even if the block is empty. (More about anchor transactions in the next section.)

2. There are validity checks performed at the node (or sometimes protocol) level as well:

   2.1 Asserts that the length of the transaction list does not exceed a predefined maximum (MAX_TX_LIST_BYTES), ensuring that the list is within the limits.

   2.2 The transaction list is (RLP) decoded into a list of transactions (txList). If the bytes are not decodeable it will result in an empty block.

   2.3 The amount of gas required to include transactions is available. (If a transaction cannot fit into a block, it is simply excluded from it, but the block is still valid with other transactions.)

   2.4 The transaction signature is valid.

   2.5 The transaction nonce is valid.

   2.6 The sender account has no contract code deployed (EIP-3607).

   2.7 The transaction's gas limit is no smaller than the intrinsic gas.

   2.8. The sender has enough balance to cover the transaction (gasLimit * gasPrice + tx.value).

Anchor transaction

The anchor transaction is a way for the protocol to make use of the programmability of the EVM (which we already need to be able to proof) to enforce certain protocol behavior. We can add additional tasks to anchor transactions to enrich Taiko’s functionalities by writing standard smart contract code (instead of requiring more complicated changes to Taiko’s ZK-EVM and node subsystems).

The anchor transaction is required to be the first transaction in a Taiko block (which is important to make the block deterministic). The anchor transaction is currently used as follows:

1. Persisting l1Height, l1Hash and l1SignalRoot to the storage trie. These values can be used by bridges to validate cross-chain messages.
2. Ensuring that the previous 256 block hashes that are exposed to the EVM are correct.
3. Calculating the EIP-1559 basefee which will be used on L2.