This document provides a comprehensive explanation of the Optimism codebase, aiming to help newcomers to Optimism quickly get started and truly understand how the code flow in the codebase works.
-
⚠️ ⚠️ ⚠️ Just a heads up, the fault proof content below is only referenced in this repository. For more detailed information on fault proof, please visit the relevant repository.
- op-e2e: End-to-End testing of all bedrock components in Go
- op-exporter: Prometheus exporter client
- op-heartbeat: Heartbeat monitor service
- op-service: Common codebase utilities
- op-wheel: Database utilities
-
00-how-sequencer-generates-L2-blocks
- The sequencer plays a critical role in Layer 2 (L2) solutions, handling transaction aggregation, L1 data derivation, L2 block generation, and proposing the L2 state root in L1. This document explains the sequencer's process for generating L2 blocks, focusing on the creation of a block payload, event loop structure, code flow for block generation, and error handling.
-
- This document discusses the block propagation process in Optimism, detailing the three types of L2 blocks (Unsafe, Safe, and Finalized) and different syncing methods, including Op-node P2P gossip sync, reverse block header sync, execution layer sync, and RPC-based sync. It includes code explanations related to enabling these sync mechanisms.
-
- The document explains how Optimism leverages the libp2p network for block propagation and reverse sync. The focus is on the networking aspects and how blocks are broadcasted using libp2p's native streaming and request-response model.
-
- The batcher is responsible for transmitting Layer 2 data to Layer 1 in an optimized manner. It collects multiple L2 blocks and combines them into channels for efficient data compression. These are then sent to Layer 1 in multiple frames to reduce costs and increase efficiency. The document includes code for how the batcher processes blocks and sends transactions to Layer 1.
-
- This file explains the derivation process in Optimism. It covers how L1 transactions are processed to derive L2 blocks, including syncing data from L1, block derivation mechanisms, and how Optimism maintains the synchronization between L1 and L2.
-
- The proposer plays a role in proposing new L2 blocks to the rollup. The document likely details how the proposer functions within the broader rollup protocol.
-
06-upgrade-of-opstack-in-EIP-4844
- This document provides an overview of the upgrade in Optimism's OPStack related to Ethereum's EIP-4844. EIP-4844 introduces "blobs" that significantly reduce data availability costs for L2. The document explains how OPStack adopts these blobs for transmitting L2 data to L1, replacing calldata with a more efficient blob format.
-
- This document covers the concept of fault proofs, a mechanism used in Optimism to detect incorrect state transitions or invalid rollup assertions.
-
- This explains the dispute resolution process in Optimism, known as the fault dispute game. It's a challenge-response game designed to resolve discrepancies between the state of the rollup and its verifiers.
-
- This file covers "Cannon," the tool used to execute the fault-proof system. Cannon facilitates state verification to ensure integrity in the rollup’s execution.
-
- This document introduces the OP Program, which describes how Optimism's fault proof mechanism integrates into the overall architecture of the protocol.
-
- This explains the OP Challenger, the entity responsible for initiating challenges in the fault-proof system.
If you have any questions or need assistance in developing public products, please don't hesitate to contact me via email at [email protected]. Should I have available time, I'd be more than happy to assist.