## op-batcher

The op-batcher is responsible for ensuring data availability.
The batch submitter, or batcher, is responsible for sending Layer 2 (L2) transaction data to Layer 1 (L1) so that verifiers can access it. Think of it like a delivery person who collects multiple small packages (L2 transactions), organizes them, and submits them to a storage facility (L1) where they can be checked later.

## How It Works
The batch submitter runs in a loop, continuously checking for new L2 transactions that need to be submitted to L1. It follows these steps
1. Check for New Data:
- The batcher looks at the latest L2 block and compares it to the last submitted (safe) block.

- If there are new transactions (unsafe blocks) that haven't been submitted, it prepares them for submission.

2. Collect & Process Data:

- The batcher goes through all new (unsafe) L2 blocks and collects transaction data that hasn’t been submitted yet.

- It compresses and encodes the data (to save space and cost).

- The data is stored in channels temporary storage units that hold multiple L2 blocks before submission.

3. Send to Layer 1:

- The batcher takes the processed data and submits it to L1.

- It follows a specific format so that the data is valid and usable.

4. Avoid Duplicates:

- After submitting, the batcher makes sure it doesn’t resend the same data.

- It keeps track of what has already been sent.

## Importants
- Ensures Data Availability: The batcher makes sure that transaction history is stored safely on L1.

- Prevents Overload: If too much data is waiting, the batcher can slow down new transactions to avoid congestion.

- Handles Errors: If something goes wrong (e.g., a transaction fails), the batcher can retry or reset itself.
- Lowers transaction costs: Bundling multiple transactions reduces gas fees.
## Key Challenges
- Reorgs: Sometimes, L2 undergoes a reorg (when its history is modified or reversed).

If this happens, the batcher resets its state and waits for L2 to stabilize before submitting new data. The batcher ensures that only the final version of L2 history is recorded on L1.

- Failed Transactions: If a submission fails, it retries without disrupting the whole system. It rewinds to the last successful submission and resends data correctly.

- Data Backlog: If too many transactions come in at once, the batcher may need to slow down processing to keep everything running smoothly.

- Preventing Data Overload (Data Availability Backlog):
L1 has a limited data throughput (how much data it can handle at a time). If L2 is too busy and generates too many transactions, the batcher may slow down submissions to prevent overwhelming L1.
This is done by throttling how much transaction data is processed at once.

## Batcher’s Core Components and Functions
The batcher operates using multiple routines (background tasks) that work together:

**1. blockLoadingLoop**
Loads new L2 blocks.

Prunes (removes) old data that is no longer needed.

Notifies the publishingLoop when new blocks are ready.

**2. publishingLoop**
Collects and processes blocks.

Compresses data and creates frames.

Sends frames to L1 as transactions.

**3. receiptsLoop**
Waits for L1 confirmation receipts.

Updates the batcher’s state.

Handles transaction failures and retries.

**4. throttlingLoop**
Monitors data congestion on L1.

If too much data is pending, it signals L2 to slow down transaction production.

In summary
The op-batcher is responsible for:
Collecting transactions from Optimism's L2 chain
Compressing and bundling them into batches
Submitting these batches to Ethereum (L1) for data availability

It ensures that all transactions processed on Optimism’s L2 are securely recorded on Ethereum’s L1.
Handle failures and retries if submission fails

## op-proposer
The op-proposer is a lightweight service that automatically submits L2 state claims to L1 at regular intervals in the Optimism network. It plays a crucial role in ensuring that Optimism’s Layer 2 (L2) blockchain remains in sync with Ethereum’s Layer 1 (L1).
(responsible for submitting L2 state commitments to Ethereum L1). It periodically generates and submits L2 output proposals, which represent snapshots of the L2 chain state at specific block heights. These proposals are stored in the L2OutputOracle contract on Ethereum.

## Core Responsibilities
- Monitor L2 chain progress: Fetch finalized L2 blocks at specific intervals.

- Generate L2 output roots: Compute a cryptographic hash of the L2 state.

- Submit to Ethereum (L1): Call the L2OutputOracle smart contract on Ethereum to store the output root.

## How It Works
- Fetch Latest Finalized L2 Block
The op-proposer connects to an L2 node (e.g., op-geth) via JSON-RPC.

- It queries the latest finalized block from the L2 execution layer.

- The proposer verifies that this block aligns with the required submission interval (e.g., every 1800 L2 blocks ≈ 1 hour).

## Compute the Output Root
The proposer constructs an L2 output root, which is a cryptographic hash summarizing the L2 state at that block.

This root is calculated using keccak256

This stores the outputRoot in the L2OutputOracle contract.

Ethereum now has a verifiable checkpoint of Optimism’s state.

## Repeating the Process
The proposer runs continuously, waiting for the next checkpoint interval.

If it fails, it retries or waits for an operator to restart it.

## Component Role
op-proposer Fetches finalized L2 state, computes output roots, and submits them to L1. L2OutputOracle (Ethereum L1) Stores L2 output roots for verification and withdrawals. op-geth (L2 Node) Provides block data and state roots to the proposer.

## Security and Fault Proofs
The L2OutputOracle allows challenges if a proposer submits an incorrect root.

Future iterations will integrate fault proofs where a challenger can prove an incorrect state update.

In Summary
The op-proposer ensures L1 has up-to-date knowledge of L2.

It fetches finalized L2 blocks, computes output roots, and submits them to Ethereum.

The L2OutputOracle stores these roots for withdrawals and security verification.