> ## Documentation Index > Fetch the complete documentation index at: https://docs.optimism.io/llms.txt > Use this file to discover all available pages before exploring further. # Rollup protocol overview > Learn how Optimistic Rollups work at a high level. export const NormativeSpec = ({what, title, href, note}) => Normative spec: {what} is normatively defined in the{" "} {title}. {note} ; The big idea that makes Optimism possible is the Optimistic Rollup. We'll go through a brief explainer of *how* Optimistic Rollups work at a high level. Then we'll explain *why* Optimism is built as an Optimistic Rollup and why we believe it's the best option for a system that addresses all of our design goals. Check out the [protocol specs](https://specs.optimism.io/?utm_source=op-docs\&utm_medium=docs), if you want more details about the rollup protocol. ## Optimistic rollups TL;DR Optimism is an "Optimistic Rollup," which is basically just a fancy way of describing a blockchain that piggy-backs off of the security of another "parent" blockchain. Specifically, Optimistic Rollups leverage the consensus mechanism (like PoW or PoS) of their parent chain instead of providing their own. In OP Mainnet's case, this parent blockchain is Ethereum. Ethereum and Optimism Forever Doodle. ## Block storage In Bedrock, L2 blocks are saved to the Ethereum blockchain using a non-contract address ([`0xff00..0010` on Ethereum](https://etherscan.io/address/0xff00000000000000000000000000000000000010)) to minimize the L1 gas expense. As these blocks are submitted as transactions using EIP-4844 [blobs](/chain-operators/guides/features/blobs), there is no way to modify or censor them after the "transaction" is included in a block that has enough attestations. This is the way that OP Mainnet inherits the availability and integrity guarantees of Ethereum. Blocks are written to L1 in [a compressed format](https://specs.optimism.io/protocol/derivation.html?utm_source=op-docs\&utm_medium=docs#batch-submission-wire-format) to reduce costs. This is important because writing to L1 is [the major cost of OP Mainnet transactions](/op-stack/transactions/fees). ## Block production Optimism block production is primarily managed by a single party, called the "sequencer," which helps the network by providing the following services: * Providing transaction confirmations and state updates. * Constructing and executing L2 blocks. * Submitting user transactions to L1. In Bedrock, the sequencer does have a mempool, similar to L1 Ethereum, but the mempool is private to avoid opening opportunities for MEV. In OP Mainnet, blocks are produced every two seconds, regardless of whether they are empty (no transactions), filled up to the block gas limit with transactions, or anything in between. Transactions get to the sequencer in two ways: 1. Transactions submitted directly to the sequencer. These transactions are a lot cheaper to submit, as they do not require the expense of a separate L1 transaction. However, they cannot be made censorship resistant since the sequencer is the only participant that knows about them. 2. Transactions submitted on L1 (called *deposits*) are included in the chain in the appropriate L2 block. Every L2 block is identified by the "epoch" (the L1 block to which it corresponds, which typically has happened a few minutes before the L2 block) and its serial number within that epoch. The first block of the epoch includes all the deposits that happened in the L1 block to which it corresponds. If the sequencer attempts to ignore a legitimate L1 transaction, it ends up with a state that is inconsistent with the verifiers, same as if the sequencer tried to fake the state by other means. This mechanism ensures that transactions submitted on L1 benefit from Ethereum's censorship resistance, even if inclusion is delayed. You can read more about this mechanism [in the protocol specifications](https://specs.optimism.io/protocol/derivation.html?utm_source=op-docs\&utm_medium=docs#deriving-the-transaction-list). For the moment, [The Optimism Foundation](https://www.optimism.io/) runs the only block producer on OP Mainnet. ## Block execution The execution engine (implemented as the `op-geth` component) receives blocks using two mechanisms: 1. The execution engine can update itself using a peer-to-peer network with other execution engines. This operates in the same way that the L1 execution clients synchronize the state across the network. You can read more about it [in the specs](https://specs.optimism.io/protocol/exec-engine.html?utm_source=op-docs\&utm_medium=docs#happy-path-sync). 2. The rollup node (implemented as the `op-node` component) derives the L2 blocks from L1. This mechanism is slower, but censorship resistant. You can read more about it [in the specs](https://specs.optimism.io/protocol/exec-engine.html?utm_source=op-docs\&utm_medium=docs#worst-case-sync). ## Bridging ETH or tokens between layers Optimism is designed so that users can send arbitrary messages between smart contracts on L2 (OP Mainnet, OP Sepolia, etc.) and the underlying L1 (Ethereum mainnet, Sepolia, etc.). This makes it possible to transfer ETH or tokens, including ERC20 tokens, between the two networks, and the Standard bridge uses this functionality to let users deposit tokens from Ethereum to OP Mainnet and withdraw them back again. Transactions going from L1 to L2 are called *deposits*; they become part of the canonical chain in the first L2 block of the "epoch" corresponding to the L1 block where the deposit was made, usually a few minutes later. Transactions going from L2 to L1 are called *withdrawals*; a withdrawal is initiated on L2, proven on L1 against an output root, and finalized on L1 only after the fault challenge period (a week on mainnet, less than that on the test network) has passed. For the step-by-step mechanics of each direction, see [Deposit flow](/op-stack/bridging/deposit-flow) and [Withdrawal flow](/op-stack/bridging/withdrawal-flow); for using the Standard bridge from an application, see the [developer documentation and examples](/app-developers/guides/bridging/standard-bridge). ## Fault proofs In an Optimistic Rollup, state commitments are published to L1 (Ethereum in the case of OP Mainnet) without any direct proof of the validity of these commitments. Instead, these commitments are considered pending for a period of time (called the "challenge window"). If a proposed state commitment goes unchallenged for the duration of the challenge window (currently set to 7 days), then it is considered final. Once a commitment is considered final, smart contracts on Ethereum can safely accept withdrawal proofs about the state of OP Mainnet based on that commitment. When a state commitment is challenged, it can be invalidated through a "fault proof" ([formerly known as a "fraud proof"](https://specs.optimism.io/fault-proof/index.html?utm_source=op-docs\&utm_medium=docs)) process. If the commitment is successfully challenged, then it is removed from the `StateCommitmentChain` to eventually be replaced by another proposed commitment. It's important to note that a successful challenge does not roll back OP Mainnet itself, only the published commitments about the state of the chain. The ordering of transactions and the state of OP Mainnet is unchanged by a fault proof challenge. ## Next steps * If you want to learn more about rollup protocol, check out the guides on [deposit flow](/op-stack/bridging/deposit-flow), [withdrawal flow](/op-stack/bridging/withdrawal-flow), or [transaction flow](/op-stack/transactions/transaction-flow). * To learn about operating your own L2 rollup, see the guide on [starting a self-hosted chain](/chain-operators/tutorials/create-l2-rollup/create-l2-rollup) or go directly to the tutorial on [creating your own L2 rollup](/chain-operators/tutorials/create-l2-rollup/create-l2-rollup).