Derivation

Table of Contents

• Overview
• Invariants
• Activation Block
• Replacing Invalid Blocks
• Network Upgrade Transactions
  • Dependency Set Conditional Transactions
  • Upgrade Block Gas Limit
• Expiry Window
• Security Considerations
  • Depositing an Executing Message
  • Expiry Window
  • Reliance on History

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 block number n is > the activation block number, see Activation Block.
• The timestamp t of the identifier MUST be:
  • t <= execution_timestamp, where execution_timestamp is the timestamp of the block that includes the executing message.
  • t > execution_timestamp - expiry_window, where expiry_window is the expiry window in seconds.

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.

Activation Block

The activation block is the first block that has a timestamp higher or equal to the Lagoon activation timestamp. The activation block timestamp may not exactly match the Lagoon activation timestamp.

The genesis block is not technically considered an activation-block, as forks are already active. However, the genesis block does not contain transactions, and thus also meets the activation criteria.

The activation block has several special properties and constraints:

• It MUST NOT include any non-deposit-type transactions. Sequencers, when building the fork activation block, MUST set noTxPool to true in the execution payload attributes for this block, instructing the builder to exclude user transactions.
• Messages MUST NOT be executed in this block. This is implemented by only processing deposit-type transactions.
• Any contract log events MUST NOT count as valid initiating messages. Verifiers may use the activation block as an anchor point, without indexing the block-contents.
• The derivation pipeline MUST enforce that the sequencer has not included any user transactions in the batch covering the upgrade's activation block. If the sequencer includes any user transactions within the activation block, this block and the remaining span batch it originated from (if part of a span batch) MUST be dropped, following the batch-dropping rules introduced in the Holocene upgrade span-batch rules.

Replacing Invalid Blocks

When the cross chain dependency resolution determines that a block contains an invalid message, the block is replaced using Holocene Replacement. The replacement block has the same attributes, except the transaction list is trimmed to include only deposit transactions.

Network Upgrade Transactions

The Lagoon activation timestamp defines the timestamp at which all functionality in this document is considered the consensus rules for an OP Stack based network.

On the activation block, in addition to the L1 attributes deposit and potentially any user deposits from L1, a set of deposit transaction-based upgrade transactions are deterministically generated by the derivation pipeline.

The contents of the transactions are defined by the file lagoon_nut_bundle.json in the monorepo, which contains 28 transactions. In addition to the contents of the file, the consensus layer node MUST prefix each intent string with Interop <index>: followed by a space, where <index> is the zero-based position of the transaction within the bundle. The prefix is the concept-level name Interop rather than the fork name Lagoon, so that the derived upgrade deposit source hashes are unaffected by the fork rename.

These transactions can be classified into the following groups:

1. Implementation Deployments: One transaction for each predeploy implementation being deployed, including the L2ContractsManager for this upgrade (27 total)
2. Upgrade Execution: One transaction to call L2ProxyAdmin.upgradePredeploys(l2ContractsManagerAddress)

More information regarding the upgrade path implemented by the bundle transactions can be found in L2 Upgrade Execution.

Dependency Set Conditional Transactions

A chain whose dependency set contains two or more chains wraps the bundle with two additional deposit transactions in the same activation block, so that the L2ContractsManager applies the Interop-gated predeploy upgrades and the ETH liquidity pool is funded:

The first transaction calls L1Block.setFeature(INTEROP), which the bundle's final upgradePredeploys call reads to decide whether to apply the Interop-gated upgrades. The second funds ETHLiquidity with a mint and value of type(uint128).max; it is the only Interop activation deposit with a non-zero mint, and therefore cannot be expressed in the bundle format.

A chain in a single-chain dependency set emits only the bundle's 28 transactions.

Upgrade Block Gas Limit

The gas added to the activation block's gas limit is specified in Custom Upgrade Block Gas Limit.

The allocation for Lagoon MUST NOT vary with the dependency set: it always covers the two conditional transactions above, even for a chain that does not emit them. A chain in a single-chain dependency set therefore carries 150,000 gas of unused headroom in its activation block.

This is required because the allocation is subtracted again when reconstructing the system configuration from the activation block, and that reconstruction has no access to the dependency set — see Gas Allocation Specification.

Expiry Window

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

Security Considerations

Depositing an Executing Message

Deposit transactions (force inclusion transactions) give censorship resistance to layer two networks. If it were possible to deposit an invalid executing message, this would force the sequencer to reorg. It would be fairly cheap to continuously deposit invalid executing messages through L1 and cause L2 liveness instability, therefore deposits are prevented from triggering executing messages.

Expiry Window

The expiry window ensures that the proof can execute in a reasonable amount of time. EIP-2935 introduced the capability to traverse history with sub-linear complexity, however deep lookups remain expensive. App developers and users, in the event that they encounter a message that has expired but has yet to be relayed, can resend the message in order to complete the process.

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.