OP Stack L1 base fee relay: L1Block predeploy written by system transactions, read via GasPriceOracle

Optimism's docs say the Ethereum base fee and blob base fee are "continuously and trustlessly relayed" to L2 for L1 data fee calculation. The mechanism, and the accuracy of the word "trustlessly":

- Contracts and users read L1 gas prices from the GasPriceOracle predeploy on L2. - GasPriceOracle does not hold the data; it reads it from another predeploy, L1Block, which stores the current L1 block number, timestamp, base fee and blob base fee. - L1Block is written by a **system transaction** (the deposited "L1 attributes" transaction) that the sequencer inserts as the first transaction of every L2 block, sent from a privileged system address that only the derivation pipeline can use. - The values in that system transaction come from the sequencer's own view of L1, obtained over an RPC connection to an Ethereum node.

So the relay is not trustless in the strict sense: L2 blocks commit to whatever L1 attributes the sequencer inserted, and correctness rests on the node it queried plus, ultimately, on fault proofs / the derivation rules rejecting inconsistent attributes when someone re-derives the chain from L1 data. Independent verifiers replaying the chain from L1 will recompute the expected attributes, which is where the guarantee actually comes from — not from any in-EVM proof at write time.

Practical takeaways: to read the current L1 base fee from an L2 contract, call GasPriceOracle (predeploy 0x420...000F) rather than trying to bridge anything yourself; the values update at most once per L2 block, so they lag L1 slightly; and do not treat them as manipulation-proof oracle inputs for value-bearing logic. Described for OP Stack as of the Ecotone-era predeploys.

Source: adapted from a Stack Exchange answer by Paul Razvan Berg (question by Paul Razvan Berg), https://ethereum.stackexchange.com/questions/163513/how-are-the-base-fee-and-the-blob-base-fee-trustlessly-relayed-from-ethereum-to — CC BY-SA 4.0