Execution Engine

1559 Parameters

The execution engine must be able to take a per chain configuration which specifies the EIP-1559 Denominator and EIP-1559 elasticity. After Canyon it should also take a new value EIP1559DenominatorCanyon and use that as the denominator in the 1559 formula rather than the prior denominator.

The formula for EIP-1559 is not otherwise modified.

Deposited transaction processing

The Engine interfaces abstract away transaction types with EIP-2718. To support rollup functionality, processing of a new Deposit TransactionType is implemented by the engine, see the deposits specification.

This type of transaction can mint L2 GLXP, run EVM, and introduce L1 information to enshrined contracts in the execution state.

Deposited transaction boundaries

Transactions cannot be blindly trusted, trust is established through authentication. Unlike other transaction types deposits are not authenticated by a signature: the rollup node authenticates them, outside of the engine.

To process deposited transactions safely, the deposits MUST be authenticated first:

• Ingest directly through trusted Engine API

• Part of sync towards a trusted block hash (trusted through previous Engine API instruction)

Deposited transactions MUST never be consumed from the transaction pool. The transaction pool can be disabled in a deposits-only rollup

Fees

Sequenced transactions (i.e. not applicable to deposits) are charged with 3 types of fees: priority fees, base fees, and L1-cost fees.

Fee Vaults

The three types of fees are collected in 3 distinct L2 fee-vault deployments for accounting purposes: fee payments are not registered as internal EVM calls, and thus distinguished better this way.

These are hardcoded addresses, pointing at pre-deployed proxy contracts. The proxies are backed by vault contract deployments, based on FeeVault, to route vault funds to L1 securely.

Vault Name	Predeploy
Sequencer Fee Vault	SequencerFeeVault
Base Fee Vault	BaseFeeVault
L1 Fee Vault	L1FeeVault

Priority fees (Sequencer Fee Vault)

Priority fees follow the EIP-1559 specification, and are collected by the fee-recipient of the L2 block. The block fee-recipient (a.k.a. coinbase address) is set to the Sequencer Fee Vault address.

Base fees (Base Fee Vault)

Base fees largely follow the EIP-1559 specification, with the exception that base fees are not burned, but add up to the Base Fee Vault GLXP account balance.

L1-Cost fees (L1 Fee Vault)

The protocol funds batch-submission of sequenced L2 transactions by charging L2 users an additional fee based on the estimated batch-submission costs. This fee is charged from the L2 transaction-sender ETH balance, and collected into the L1 Fee Vault.

The exact L1 cost function to determine the L1-cost fee component of a L2 transaction depends on the upgrades that are active.

Hardfork Ecotone

Before Ecotone activation, L1 cost is calculated as: (rollupDataGas + l1FeeOverhead) * l1BaseFee * l1FeeScalar / 1e6 (big-int computation, result in Wei and uint256 range) Where:

• rollupDataGas is determined from the full encoded transaction (standard EIP-2718 transaction encoding, including signature fields):

• Before Regolith fork: rollupDataGas = zeroes * 4 + (ones + 68) * 16

• The addition of 68 non-zero bytes is a remnant of a pre-Bedrock L1-cost accounting function, which accounted for the worst-case non-zero bytes addition to complement unsigned transactions, unlike Bedrock.

• With Regolith fork: rollupDataGas = zeroes * 4 + ones * 16

• l1FeeOverhead is the Gas Price Oracle overhead value.

• l1FeeScalar is the Gas Price Oracle scalar value.

• l1BaseFee is the L1 base fee of the latest L1 origin registered in the L2 chain.

Note that the rollupDataGas uses the same byte cost accounting as defined in eip-2028, except the full L2 transaction now counts towards the bytes charged in the L1 calldata. This behavior matches pre-Bedrock L1-cost estimation of L2 transactions.

Compression, batching, and intrinsic gas costs of the batch transactions are accounted for by the protocol with the Gas Price Oracle overhead and scalar parameters.

The Gas Price Oracle l1FeeOverhead and l1FeeScalar, as well as the l1BaseFee of the L1 origin, can be accessed in two interchangeable ways:

• read from the deposited L1 attributes (l1FeeOverhead, l1FeeScalar, basefee) of the current L2 block

• Read from the L1 Block Info contract (0x4200000000000000000000000000000000000015)

• Using the respective solidity uint256-getter functions (l1FeeOverhead, l1FeeScalar, basefee)

• Using direct storage-reads:

  • L1 basefee as big-endian uint256 in slot 1

  • Overhead as big-endian uint256 in slot 5

  • Scalar as big-endian uint256 in slot 6

Engine API

engine_forkchoiceUpdatedV2

This updates which L2 blocks the engine considers to be canonical (forkchoiceState argument), and optionally initiates block production (payloadAttributes argument).

Within the rollup, the types of forkchoice updates translate as:

• headBlockHash: block hash of the head of the canonical chain. Labeled "unsafe" in user JSON-RPC. Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts.

• safeBlockHash: block hash of the canonical chain, derived from L1 data, unlikely to reorg.

• finalizedBlockHash: irreversible block hash, matches lower boundary of the dispute period.

To support rollup functionality, one backwards-compatible change is introduced to engine_forkchoiceUpdatedV2: the extended PayloadAttributesV2

Beacon Block Root

EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM. This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block.

With the adoption of EIP-4399 in the Bedrock upgrade the Glide already includes the PREVRANDAO of L1. And thus with EIP-4788 the L1 beacon block root is made available.

For the Ecotone upgrade, this entails that:

• The parent_beacon_block_root of the L1 origin is now embedded in the L2 block header.

• The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.

• The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.

P2P Modifications

The Ethereum Node Record (ENR) for an Optimism execution node must contain an opel key-value pair where the key is opel and the value is a EIP-2124 fork id. The EL uses a different key from the CL in order to stop EL and CL nodes from connecting to each other.