Derivation

Table of Contents

Overview

New derivation rules are added to guarantee integrity of cross chain messages. The fork choice rule is updated to fork out unsafe blocks that contain invalid executing messages.

Invariants

  • An executing message MUST have a corresponding initiating message
  • The initiating message referenced in an executing message MUST come from a chain in its dependency set
  • A block MUST be considered invalid if it is built with any invalid executing messages
  • The timestamp of the identifier MUST be greater than or equal to the interop network upgrade timestamp
  • The timestamp of the identifier MUST be less than or equal to the timestamp of the block that includes it
  • The timestamp of the identifier MUST be greater than timestamp of the block that includes it minus the expiry window

L2 blocks that produce invalid executing messages MUST not be allowed to be considered safe. They MAY optimistically exist as unsafe blocks for some period of time. An L2 block that is invalidated because it includes invalid executing messages MUST be replaced by a deposits only block at the same block height. This guarantees progression of the chain, ensuring that an infinite loop of processing the same block in the proof system is not possible.

Replacing Invalid Blocks

When the cross chain dependency resolution determines that a block contains an invalid message, the block is replaced by a block with the same inputs, except for the transactions included. The transactions from the original block are trimmed to include only deposit transactions plus an optimistic block info deposit transaction, which is appended to the trimmed transaction list.

Optimistic Block Deposited Transaction

An Optimistic Block Deposited Transaction is a system deposited transaction, inserted into the replacement block, to signal when a previously derived local-safe block (the "optimistic" block) was invalidated.

This transaction MUST have the following values:

  1. from is 0xdeaddeaddeaddeaddeaddeaddeaddeaddead0002, like the address of the L1 Attributes depositor account, but incremented by 1
  2. to is 0x0000000000000000000000000000000000000000 (the zero address as no EVM code execution is expected).
  3. mint is 0
  4. value is 0
  5. gasLimit is set 36000 gas, to cover intrinsic costs, processing costs, and margin for change.
  6. isSystemTx is set to false.
  7. data is the preimage of the L2 output root of the replaced block. i.e. version_byte || payload without applying the keccak256 hashing.
  8. sourceHash is computed with a new deposit source-hash domain, see below.

This system-initiated transaction for L1 attributes is not charged any ETH for its allocated gasLimit, as it is considered part of state-transition processing.

Optimistic Block Source-hash

The source hash is computed with a source-hash domain: 4 (instead of 1), combined with the L2 output root of the optimistic block that was invalidated.

The source-hash is thus computed as: keccak256(bytes32(uint256(4)), outputRoot)).

Network Upgrade Transactions

The interop network upgrade timestamp defines the timestamp at which all functionality in this document is considered the consensus rules for an OP Stack based network. On the interop network upgrade block, a set of deposit transaction based upgrade transactions are deterministically generated by the derivation pipeline in the following order:

  • L1 Attributes Transaction calling setL1BlockValuesIsthmus
  • User deposits from L1
  • Network Upgrade Transactions
    • CrossL2Inbox deployment
    • L2ToL2CrossDomainMessenger deployment
    • OptimismMintableERC20Factory deployment
    • Update CrossL2Inbox Proxy ERC-1967 Implementation Slot
    • Update L2ToL2CrossDomainMessenger Proxy ERC-1967 Implementation Slot
    • Update the OptimismMintableERC20Factory Proxy ERC-1967 Implementation Slot

The execution payload MUST set noTxPool to true for this block.

Expiry Window

The expiry window is the time period after which an initiating message is no longer considered valid.

ConstantValue
EXPIRY_WINDOWTODO

Security Considerations

Depositing an Executing Message

Deposit transactions (force inclusion transactions) give censorship resistance to layer two networks. It is possible to deposit an invalid executing message, forcing the sequencer to reorg. It would be fairly cheap to continuously deposit invalid executing messages through L1 and cause L2 liveness instability. A future upgrade will enable deposits to trigger executing messages.

Reliance on History

When fully executing historical blocks, a dependency on historical receipts from remote chains is present. EIP-4444 will eventually provide a solution for making historical receipts available without needing to execute increasingly long chain histories.

Expiry Window

The expiry window ensures that the proof can execute in a reasonable amount of time. There is currently no way to prove old history with a sublinear proof size. The proof program needs to walk back and re-execute to reproduce the consumed logs. This means that very old logs are more expensive to prove.