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.
watch the talks given by OP Labs’ Karl Floersch and Kelvin Fichter at Devcon 6
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.
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
Note: step 4 is related to the concept of finalized L2 head.
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.
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.
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
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
Fork Choice Rule: to determine the blockchain head
Time Slot: every 2 second per L2 block