Disclaimer: My goal is to learn the OP Bedrock protocol quickly so I can understand the code more easily to be able to plug in with my own DA layer to the OP stack. So I only read the things I think that can be helpful. The goal is not to understand every piece of the details.

Study Steps

1. read Introducing the OP Stack

2. watch the talks given by OP Labs’ Karl Floersch and Kelvin Fichter at Devcon 6

3. read the following specs: Introduction, Overview, Deposits, Rollup Node, Batch Submitter, System Config, L2 Chain Derivation(*)

*: for the derivation spec, I started to skip lots of the details from section Batch Queue

It should take ~2-3 days to study everything on this list.

High-level

• The OP stack is modular and minimal. It’s easy to swap with your own e.g. consensus, DA layers. The Superchain vision is able to scale horizontally.

• Example: Metis forked OP and customized the DA layer with a DA committee

• The 3 primary layers

  • Consensus

    • DA: an array of byte strings. not necessary a ledger

    • Derivation: takes the DA layer and the current state of the rollup and produces Engine API payloads

  • Execution: state transition

  • Settlement: a view that another chain has over your chain

Key Interactions

Note: step 4 is related to the concept of finalized L2 head.

Overview

The L2OutputOracle is a L1 contract to store rollup states (i.e. L2 output roots) and manage withdrawals. It will be helpful to think of it as the rollup output store and DepositFeed and BatchInbox as the rollup input store. So the L1 is simply the DA layer for storing rollup inputs and outputs, and the L2 is the computing layer.

DepositFeed is for a special transaction type (i.e. Deposited Transaction) on L2 defined by the Optimism protocol. BatchInbox is for the other normal L2 transactions (i.e. only transaction inputs) that are batch-submitted to L1.

It’s also useful to know that the BatchInbox is a regular EOA address (note: for saving gas cost by not executing any EVM code). The sequencer submits L2 transaction batches included in the calldata of the L1 transaction to the address.

Key Concepts

• Block Derivation

• Epochs and the Sequencing Window

• Deposited Transactions: This is a new transaction type on L2 defined by the protocol.

  • It’s important to understand that when tokens are deposited from L1 to L2, it’s technically “depositing the transactions to the L2“. The tokens are locked on L1 and then minted on L2.

  • deposited transactions do not need a signature and rely on other mechanisms for authorization and validation

  • L1 attributes deposited transaction and user-deposited transactions

  • L1 Attributes Depositor Account: an EOA with unknown private key.

  • L1 Attributes Predeployed Contract: it’s important to know that the contract will be called in the first transaction of every L2 block (source). Every L2 block has an L1 attributes tx.

  • Address Aliasing

• Batch Submission

  • Data Availability Provider (e.g. Ethereum calldata)

  • Sequencer Batch: each batch represents the inputs needed to build one L2 block

  • Batcher Transaction: a transaction submitted by a batcher to a data availability provider

  • Channel and Channel Frame

  • The diagram below illustrates these concepts as a whole

• L2 Chain Derivation

  • L2 Derivation Inputs

  • System Config: batcherHash stores the current authorized batcher sender(s)

  • Payload Attributes: object to be passed to the execution engine

  • L2 Chain Inception: the L1 block number where the L2 genesis starts

  • Finalized L2 Head, Safe L2 Head, Unsafe L2 Head, Unsafe Block Consolidation

    • it’s important to distinguish the difference of finalizing the L2 head with the concept of finalization period. The former form of finalization only affects inputs while the later affects Optimistic-rollup outputs.

• Fork Choice Rule: to determine the blockchain head

• Time Slot: every 2 second per L2 block