🧻
Rollup Economics Research (ROP-3)
/
Optimism Specs (Condensed)
/
17. Glossary

17. Glossary

1. General Terms
Predeployed Contract (Predeploy)
  • A contract placed in the L2 genesis state.
 
Receipt
  • Output generated by a transaction, comprising of:
    • A status code
    • The amount of gas used
    • List of log entries
    • Bloom filter for indexing log entries
  • Receipts are not stored in blocks. But the blocks do store the transaction trie receipt for every transaction in the block (thus easy to compute from execution).
 
Transaction Type
  • EIP-2718 defines different transaction types.
  • Different transaction types contain different payloads.
 
Fork Choice Rule
  • Rule used to determine which block is the head of the blockchain.
  • On L1 → Proof of Stake rules (Gasper FFG and GHOST)
  • On L2 → rules vary depending on whether we want:
    • safe L2 head
    • unsafe L2 head
    • finalised L2 head
      •  
2. Sequencing
💡
Transactions in the rollup can be included in 2 ways: 1. Through deposited transaction (directly to L1) 2. Through regular transaction (in sequencer batch) Submitting transactions to sequencer saves costs and enables the sequencer to pre-confirm transactions before L1 confirms the data.
Sequencer
  • Can be either:
    • Rollup node ran in sequencer mode.
    • Operator of this rollup node.
  • Sequencer is a privileged actor.
  • Sequencer receives L2 transactions from users.
  • Sequencer creates L2 blocks using received transactions.
  • Sequencer submits L2 blocks to a DA provider (via a batcher).
  • Sequencer submits output roots to L1.
 
Sequencing Window
  • This is a range of L1 blocks from which a sequencing epoch can be derived.
 
💡
We have a sequencing window: - The 1st L1 block of the window has number N . - This L1 block contains batcher transactions for epoch N. - The sequencing window contains the range of the following L1 blocks labeled by number, [N, N + SWS) . - SWS = sequencer window size - 1st L1 block of window contains depositing transactions which determine the deposits to be included in the first LW block of the epoch.
 
Sequencing Epoch
  • This is a sequential range of L2 blocks derived from a sequencing window of L1 blocks.
  • Each epoch is identified by an epoch number.
    • equal to the block number of the first L1 block in the sequencing window.
 
L1 Origin
  • This is a field of an L2 block.
  • It refers to the L1 block corresponding to its sequencing to its sequencing epoch.
 
3. Deposits
 
💡
A deposit is an L2 transaction derived from an L1 block. This is performed by the rollup driver.
 
Deposited Transaction
  • A L2 transaction derived from L1 and included in a L2 block.
  • 2 kinds of deposited transactions:
      1. L1 attributes deposited transactions: submits L1 block attributes to the L1 Attributes Predeployed Contract.
      1. User-deposited transactions: transactions derived from an L1 call to the deposit contract (OptimismPortal Contract).
 
L1 Attributes Deposited Transaction (L2 transaction)
  • Deposited Transaction on L2.
  • Used to register the L1 block attributes on L2 (via call to L1 Attributes Predeployed Contract).
 
User-Deposited Transaction (L2 transaction)
  • Deposited Transaction on L2.
  • Derived from an L1 call to the deposit contract.
 
Depositing Call (L1 contract call)
  • A L1 call to the deposit contract.
  • Rollup driver uses this to derive the deposit transaction on L2 (by listening for the deposit events emitted by the L1 contract).
 
Depositing Transaction (L1 transaction)
  • L1 Transaction that makes one more depositing calls.
 
Depositor
  • L1 account (contract or EOA) that makes the depositing call.
    • Depositor is the msg.sender (but is NOT the originator of the depositing transaction i.e. tx.origin).
 
Deposited Transaction Type
  • EIP-2718 transaction type on L2.
  • 0x7E is the type number.
 
Deposit Contract (on L1)
  • L1 contract which accounts may send deposits to.
  • Deposits are emitted as log events for consumption by rollup nodes.
 
4. Withdrawals
 
💡
A withdrawal is a transaction sent from L2 to L1 that may transfer data and/or value.
 
  • Withdrawal initiating transaction = L2 transaction sent to the Withdrawals Predeployed Contract.
  • Withdrawal finalising transaction = L1 transaction which finalises and relays the withdrawal.
 
Relayer (L1 EOA)
  • A L1 EOA which finalises a withdrawal.
    • It submits data needed to verify its inclusion on L2.
Finalisation Period
  • The minimum amount of time that must elapse before withdrawal can be finalised.
  • It is necessary to afford sufficient time for validators to make a fault proof.
 
5. Batch Submission
Data Availability
  • Guarantees that data will be available (and retrievable) during a reasonably long time window.
  • This data refers to sequencer batches that validators need in order to verify the sequencer’s work and validate the L2 chain.
  • DA is most crucial when we need to make use of fault proofs.
  • Availability does not guarantee long-term storage of the data.
Data Availability Provider
  • A service that can be used to make data available.
  • Provides strong, verifiable guarantees of data availability.
  • Currently the only supported DA provider is Ethereum calldata.
  • In the future, Ethereum data blobs will also be supported.
Sequencer Batch
  • A list of L2 transactions submitted to a sequencer.
  • This batch is tagged with an epoch number and an L2 block timestamp.
    • This can trivially be converted to a block number, given Optimism block time is constant.
  • These batches are part of the L2 derivation inputs.
  • Each batch represents the inputs needed build one L2 block (given existing L2 chain state).
    • Special Case: The first block of the epoch requires also the information about deposits.
Channel
  • A sequence of sequencer batches (for sequential blocks) compressed together.
    • Multiple batches are grouped together to obtain a better compression rate.
  • Channels can be split in frames in order to be transmitted via batcher transactions.
  • Channels are uniquely identified by its timestamp and a random value.
  • The rollup node is the consumer of channels.
  • A channel is considered to be opened if its final frame (explicitly labeled) has not been read, or closed otherwise.
Channel Frame
  • A chunk of data belonging to a channel.
  • Batcher transactions carry one or multiple frames.
  • If a channel is too large to include in a single batcher transaction, we split a channel into frames.
Batcher
  • A software component that is responsible for making channels available on a DA provider (right now this means the calldata).
  • The batcher communicates with the rollup node in order to retrieve the channels.
    • The channels are then made available using batcher transactions.
Batcher Transaction
  • A transaction submitted by a batcher to a DA provider.
  • These transactions carry one or more full frames, which may belong to different channels.
  • A channel’s frame may be split between multiple batcher transactions.
  • When submitting to Ethereum calldata, the batcher transaction’s recipient must be the sequencer inbox address.
    • The transaction is required to be signed by a recognised batch submitter account.
Channel Timeout
  • A duration (in L1 blocks) during which channel frames may land on L1 within batcher transactions.
  • Acceptable time range for frames of a channel = [channel_id.timestamp, channel_id.timestamp + CHANNEL_TIMEOUT] .
    • Acceptable L1 block range for these frames are any L1 blocks whose timestamp falls within the time range.
  • Purpose of channel timeouts:
      1. Avoid keeping old, unclosed channel data around forever.
      1. Bound the number of L1 blocks we need to look back at to decode sequencer batches from channels.
 
6. L2 Chain Derivation
💡
L2 chain derivation is a process that reads L2 derivation inputs from L1 to derive the L2 chain.
 
L2 Derivation Inputs
  • Data that is found in L1 blocks and is read by the rollup node to construct payload attributes.
  • Inputs include:
      1. L1 block attributes
          • block number
          • timestamp
          • basefee
      1. Deposits (as log data)
      1. Sequencer batches (as transaction data)
      1. System configuration updates (as log data)
 
System Configuration
  • The collection of dynamically configurable rollup parameters maintained by the SystemConfig contract on L1 and read by the L2 derivation process.
  • These parameters enable keys to be rotated regularly.
  • These parameters enable external cost parameters to be adjusted without requiring hard forks.
 
Payload Attributes
  • An object that can be derived from L2 chain derivation inputs found on L1, which are then passed to the execution engine to construct L2 blocks.
  • This object encodes a block without output properties.
 
L2 Genesis Block
  • The first block of the L2 chain in its current version.
  • State of the L2 genesis block includes:
    • State inherited from previous versions of the L2 chain.
    • Predeployed contracts
  • Timestamp of L2 genesis block must be a multiple of the block time.
 
L2 Chain Inception
  • The L1 block number at which the output roots for the genesis block were proposed on the output oracle contract.
Safe L2 Block
  • An L2 block that is derived entirely from L1 by a rollup node.
Safe L2 Head
  • The highest safe L2 block that a rollup node knows about.
Unsafe L2 Block
  • An L2 block that a rollup node knows about but which was not derived from the L1 chain.
  • In sequencer mode, this is a block sequenced by the sequencer itself.
  • In validator mode, this is a block acquired from the sequencer via unsafe sync.
Unsafe L2 Head
  • The highest unsafe L2 block that a rollup node knows about.
Unsafe Block Consolidation
  • The process through which the rollup node attempts to move the safe L2 head a block forward, so that the oldest unsafe L2 block becomes the new safe L2 head.
  • To perform consolidation, the node verifies that the payload attributes derived from the L1 chain match the oldest unsafe L2 block exactly.
    • Look at Engine Queue documentation.
Finalised L2 Head
 
7. Other L2 Chain Concepts
Address Aliasing
  • Modified representation of the address of a contract on L2.
  • When a contract submits a deposit from L1 to L2, its address is aliased with a modified representation of the address of the contract on L2.
Rollup Node
  • Responsible for deriving the L2 chain from the L1 chain (using L1 blocks and their receipts).
  • Can be run in either validator mode or sequencer mode.
  • In sequencer mode:
    • Rollup node receives L2 transactions from users, which it uses to create L2 blocks.
    • These are then submitted to a DA provider via batch submission.
    • L2 chain derivation is a sanity check + way to detect L1 chain re-orgs.
  • In validator mode (replica):
    • Rollup node performs L2 chain derivation.
    • Is also able to run ahead of the L1 chain by getting blocks directly from the sequencer.
Rollup Driver
  • Rollup node component responsible for executing derivation logic for deriving the L2 chain from the L1 chain.
L1 Attributes Predeployed Contract
  • A predeployed contract on L2 used to retrieve L1 block attributes of L1 blocks (using number or hash).
L2 Output Root
  • A 32 byte value representing a commitment to the current state of the L2 chain.
L2 Output Oracle Contract
  • An L1 contract to which L2 output roots are posted to by the sequencer.
Validator
  • An entity that runs a rollup node in validator mode.
  • Validators can simulate L2 transactions locally, without rate limiting.
  • Validators can verify the work of the sequencer.
    • Re-deriving output roots and comparing them against those submitted by the sequencer.
    • Performing fault proof if appropriate.
Fault Proof
  • An on-chain interactive proof, performed by validators demonstrating that a sequencer provided incorrect output roots.
Time Slot
  • Every 2 second interval following the timestamp of the L2 genesis block.
Block Time
  • 2 seconds, meaning there is an L2 block at every 2 second time slot.
Unsafe Sync
  • The process through which a validator learns about unsafe L2 blocks from the sequencer.
  • The discovered unsafe L2 blocks need to be confirmed by the L1 chain (via unsafe block consolidation)
 
8. Execution Engine Concepts
💡
Execution Engine is the explicit component that executes L2 transactions. It uses transactions derived from L1 blocks to construct the L2 transactions and execute them.
Execution Engine
  • Responsible for executing transactions in blocks and computing the resulting state roots, receipts roots and block hash.
  • On L2, executed blocks are freshly minted by the execution engine at the request of the rollup node, using transactions derived from L1 blocks.
 
🧻
Rollup Economics Research (ROP-3)
/
Optimism Specs (Condensed)
/
17. Glossary

17. Glossary

1. General Terms
Predeployed Contract (Predeploy)
  • A contract placed in the L2 genesis state.
 
Receipt
  • Output generated by a transaction, comprising of:
    • A status code
    • The amount of gas used
    • List of log entries
    • Bloom filter for indexing log entries
  • Receipts are not stored in blocks. But the blocks do store the transaction trie receipt for every transaction in the block (thus easy to compute from execution).
 
Transaction Type
  • EIP-2718 defines different transaction types.
  • Different transaction types contain different payloads.
 
Fork Choice Rule
  • Rule used to determine which block is the head of the blockchain.
  • On L1 → Proof of Stake rules (Gasper FFG and GHOST)
  • On L2 → rules vary depending on whether we want:
    • safe L2 head
    • unsafe L2 head
    • finalised L2 head
      •  
2. Sequencing
💡
Transactions in the rollup can be included in 2 ways: 1. Through deposited transaction (directly to L1) 2. Through regular transaction (in sequencer batch) Submitting transactions to sequencer saves costs and enables the sequencer to pre-confirm transactions before L1 confirms the data.
Sequencer
  • Can be either:
    • Rollup node ran in sequencer mode.
    • Operator of this rollup node.
  • Sequencer is a privileged actor.
  • Sequencer receives L2 transactions from users.
  • Sequencer creates L2 blocks using received transactions.
  • Sequencer submits L2 blocks to a DA provider (via a batcher).
  • Sequencer submits output roots to L1.
 
Sequencing Window
  • This is a range of L1 blocks from which a sequencing epoch can be derived.
 
💡
We have a sequencing window: - The 1st L1 block of the window has number N . - This L1 block contains batcher transactions for epoch N. - The sequencing window contains the range of the following L1 blocks labeled by number, [N, N + SWS) . - SWS = sequencer window size - 1st L1 block of window contains depositing transactions which determine the deposits to be included in the first LW block of the epoch.
 
Sequencing Epoch
  • This is a sequential range of L2 blocks derived from a sequencing window of L1 blocks.
  • Each epoch is identified by an epoch number.
    • equal to the block number of the first L1 block in the sequencing window.
 
L1 Origin
  • This is a field of an L2 block.
  • It refers to the L1 block corresponding to its sequencing to its sequencing epoch.
 
3. Deposits
 
💡
A deposit is an L2 transaction derived from an L1 block. This is performed by the rollup driver.
 
Deposited Transaction
  • A L2 transaction derived from L1 and included in a L2 block.
  • 2 kinds of deposited transactions:
      1. L1 attributes deposited transactions: submits L1 block attributes to the L1 Attributes Predeployed Contract.
      1. User-deposited transactions: transactions derived from an L1 call to the deposit contract (OptimismPortal Contract).
 
L1 Attributes Deposited Transaction (L2 transaction)
  • Deposited Transaction on L2.
  • Used to register the L1 block attributes on L2 (via call to L1 Attributes Predeployed Contract).
 
User-Deposited Transaction (L2 transaction)
  • Deposited Transaction on L2.
  • Derived from an L1 call to the deposit contract.
 
Depositing Call (L1 contract call)
  • A L1 call to the deposit contract.
  • Rollup driver uses this to derive the deposit transaction on L2 (by listening for the deposit events emitted by the L1 contract).
 
Depositing Transaction (L1 transaction)
  • L1 Transaction that makes one more depositing calls.
 
Depositor
  • L1 account (contract or EOA) that makes the depositing call.
    • Depositor is the msg.sender (but is NOT the originator of the depositing transaction i.e. tx.origin).
 
Deposited Transaction Type
  • EIP-2718 transaction type on L2.
  • 0x7E is the type number.
 
Deposit Contract (on L1)
  • L1 contract which accounts may send deposits to.
  • Deposits are emitted as log events for consumption by rollup nodes.
 
4. Withdrawals
 
💡
A withdrawal is a transaction sent from L2 to L1 that may transfer data and/or value.
 
  • Withdrawal initiating transaction = L2 transaction sent to the Withdrawals Predeployed Contract.
  • Withdrawal finalising transaction = L1 transaction which finalises and relays the withdrawal.
 
Relayer (L1 EOA)
  • A L1 EOA which finalises a withdrawal.
    • It submits data needed to verify its inclusion on L2.
Finalisation Period
  • The minimum amount of time that must elapse before withdrawal can be finalised.
  • It is necessary to afford sufficient time for validators to make a fault proof.
 
5. Batch Submission
Data Availability
  • Guarantees that data will be available (and retrievable) during a reasonably long time window.
  • This data refers to sequencer batches that validators need in order to verify the sequencer’s work and validate the L2 chain.
  • DA is most crucial when we need to make use of fault proofs.
  • Availability does not guarantee long-term storage of the data.
Data Availability Provider
  • A service that can be used to make data available.
  • Provides strong, verifiable guarantees of data availability.
  • Currently the only supported DA provider is Ethereum calldata.
  • In the future, Ethereum data blobs will also be supported.
Sequencer Batch
  • A list of L2 transactions submitted to a sequencer.
  • This batch is tagged with an epoch number and an L2 block timestamp.
    • This can trivially be converted to a block number, given Optimism block time is constant.
  • These batches are part of the L2 derivation inputs.
  • Each batch represents the inputs needed build one L2 block (given existing L2 chain state).
    • Special Case: The first block of the epoch requires also the information about deposits.
Channel
  • A sequence of sequencer batches (for sequential blocks) compressed together.
    • Multiple batches are grouped together to obtain a better compression rate.
  • Channels can be split in frames in order to be transmitted via batcher transactions.
  • Channels are uniquely identified by its timestamp and a random value.
  • The rollup node is the consumer of channels.
  • A channel is considered to be opened if its final frame (explicitly labeled) has not been read, or closed otherwise.
Channel Frame
  • A chunk of data belonging to a channel.
  • Batcher transactions carry one or multiple frames.
  • If a channel is too large to include in a single batcher transaction, we split a channel into frames.
Batcher
  • A software component that is responsible for making channels available on a DA provider (right now this means the calldata).
  • The batcher communicates with the rollup node in order to retrieve the channels.
    • The channels are then made available using batcher transactions.
Batcher Transaction
  • A transaction submitted by a batcher to a DA provider.
  • These transactions carry one or more full frames, which may belong to different channels.
  • A channel’s frame may be split between multiple batcher transactions.
  • When submitting to Ethereum calldata, the batcher transaction’s recipient must be the sequencer inbox address.
    • The transaction is required to be signed by a recognised batch submitter account.
Channel Timeout
  • A duration (in L1 blocks) during which channel frames may land on L1 within batcher transactions.
  • Acceptable time range for frames of a channel = [channel_id.timestamp, channel_id.timestamp + CHANNEL_TIMEOUT] .
    • Acceptable L1 block range for these frames are any L1 blocks whose timestamp falls within the time range.
  • Purpose of channel timeouts:
      1. Avoid keeping old, unclosed channel data around forever.
      1. Bound the number of L1 blocks we need to look back at to decode sequencer batches from channels.
 
6. L2 Chain Derivation
💡
L2 chain derivation is a process that reads L2 derivation inputs from L1 to derive the L2 chain.
 
L2 Derivation Inputs
  • Data that is found in L1 blocks and is read by the rollup node to construct payload attributes.
  • Inputs include:
      1. L1 block attributes
          • block number
          • timestamp
          • basefee
      1. Deposits (as log data)
      1. Sequencer batches (as transaction data)
      1. System configuration updates (as log data)
 
System Configuration
  • The collection of dynamically configurable rollup parameters maintained by the SystemConfig contract on L1 and read by the L2 derivation process.
  • These parameters enable keys to be rotated regularly.
  • These parameters enable external cost parameters to be adjusted without requiring hard forks.
 
Payload Attributes
  • An object that can be derived from L2 chain derivation inputs found on L1, which are then passed to the execution engine to construct L2 blocks.
  • This object encodes a block without output properties.
 
L2 Genesis Block
  • The first block of the L2 chain in its current version.
  • State of the L2 genesis block includes:
    • State inherited from previous versions of the L2 chain.
    • Predeployed contracts
  • Timestamp of L2 genesis block must be a multiple of the block time.
 
L2 Chain Inception
  • The L1 block number at which the output roots for the genesis block were proposed on the output oracle contract.
Safe L2 Block
  • An L2 block that is derived entirely from L1 by a rollup node.
Safe L2 Head
  • The highest safe L2 block that a rollup node knows about.
Unsafe L2 Block
  • An L2 block that a rollup node knows about but which was not derived from the L1 chain.
  • In sequencer mode, this is a block sequenced by the sequencer itself.
  • In validator mode, this is a block acquired from the sequencer via unsafe sync.
Unsafe L2 Head
  • The highest unsafe L2 block that a rollup node knows about.
Unsafe Block Consolidation
  • The process through which the rollup node attempts to move the safe L2 head a block forward, so that the oldest unsafe L2 block becomes the new safe L2 head.
  • To perform consolidation, the node verifies that the payload attributes derived from the L1 chain match the oldest unsafe L2 block exactly.
    • Look at Engine Queue documentation.
Finalised L2 Head
 
7. Other L2 Chain Concepts
Address Aliasing
  • Modified representation of the address of a contract on L2.
  • When a contract submits a deposit from L1 to L2, its address is aliased with a modified representation of the address of the contract on L2.
Rollup Node
  • Responsible for deriving the L2 chain from the L1 chain (using L1 blocks and their receipts).
  • Can be run in either validator mode or sequencer mode.
  • In sequencer mode:
    • Rollup node receives L2 transactions from users, which it uses to create L2 blocks.
    • These are then submitted to a DA provider via batch submission.
    • L2 chain derivation is a sanity check + way to detect L1 chain re-orgs.
  • In validator mode (replica):
    • Rollup node performs L2 chain derivation.
    • Is also able to run ahead of the L1 chain by getting blocks directly from the sequencer.
Rollup Driver
  • Rollup node component responsible for executing derivation logic for deriving the L2 chain from the L1 chain.
L1 Attributes Predeployed Contract
  • A predeployed contract on L2 used to retrieve L1 block attributes of L1 blocks (using number or hash).
L2 Output Root
  • A 32 byte value representing a commitment to the current state of the L2 chain.
L2 Output Oracle Contract
  • An L1 contract to which L2 output roots are posted to by the sequencer.
Validator
  • An entity that runs a rollup node in validator mode.
  • Validators can simulate L2 transactions locally, without rate limiting.
  • Validators can verify the work of the sequencer.
    • Re-deriving output roots and comparing them against those submitted by the sequencer.
    • Performing fault proof if appropriate.
Fault Proof
  • An on-chain interactive proof, performed by validators demonstrating that a sequencer provided incorrect output roots.
Time Slot
  • Every 2 second interval following the timestamp of the L2 genesis block.
Block Time
  • 2 seconds, meaning there is an L2 block at every 2 second time slot.
Unsafe Sync
  • The process through which a validator learns about unsafe L2 blocks from the sequencer.
  • The discovered unsafe L2 blocks need to be confirmed by the L1 chain (via unsafe block consolidation)
 
8. Execution Engine Concepts
💡
Execution Engine is the explicit component that executes L2 transactions. It uses transactions derived from L1 blocks to construct the L2 transactions and execute them.
Execution Engine
  • Responsible for executing transactions in blocks and computing the resulting state roots, receipts roots and block hash.
  • On L2, executed blocks are freshly minted by the execution engine at the request of the rollup node, using transactions derived from L1 blocks.
Â