---
title: "Optimistic Rollups"
description: "Bereitstellungsspezifischer Leitfaden zu Sequencer-Belegen, L1-Ableitungsdaten, Unsafe-/Safe-/Finalized-Heads, Fault-Proof-Spielen, kanonischen Auszahlungen, Governance und Fast Exits."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Optimistic Rollups
> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
Ein Optimistic Rollup führt einen geordneten Transaktionsstrom aus und veröffentlicht protokolldefinierte Ableitungsdaten und State Claims, ohne jedem Batch einen Gültigkeitsnachweis beizufügen. „Optimistic“ bedeutet, dass ein zulässiger Claim nach den bereitgestellten Regeln fortschreiten kann, solange kein erfolgreicher Fault-Proof-Streit seine Fehlerhaftigkeit belegt. Eine Sequencer-Nachricht beweist weder Korrektheit, noch bietet jede Implementierung erlaubnisfreie Anfechtungen oder dieselbe Auszahlungsfrist.
Rollup Nodes leiten L2-Blöcke unabhängig aus kanonischen L1-Eingaben und der genauen Protokollkonfiguration ab. Der Sicherheitspfad umfasst daher Datenverfügbarkeit, korrekte Ableitung und Ausführung, ein aktives und korrektes Fault-Proof-System, L1-Zugang und -Finalität, Governance sowie Bridge-Kontrakte. Ein State Root allein reicht weder zur Rekonstruktion der Chain noch zur Anfechtung eines ungültigen Übergangs.
## Funktionsweise
1. Legen Sie die Bereitstellung fest: L1- und L2-Chain-IDs, Rollup-Konfiguration und Fork, Inbox- und Bridge-Kontrakte, Batchformat und DA-Modus, State-Claim- und Dispute-Game-Kontrakte, Portal-Version, Administratoren, Guardians und Beobachtungsblock. Stack-Dokumentation beweist nicht, dass jede Funktion auf einer benannten Chain aktiv ist.
2. Klassifizieren Sie den beobachteten Zustand. Ein Sequencer-Beleg oder Unsafe Block ist eine schnelle lokale Ordnungszusage; ein auf L1 veröffentlichter Batch kann einen sicher abgeleiteten Safe Head stützen; L1-Finalität kann einen abgeleiteten Finalized Head stützen. State- oder Output-Claim, gelöster Streit und ausführbare Auszahlung sind getrennte Objekte mit getrennten Fristen.
3. Rekonstruieren Sie die L1-zu-L2-Ableitung. Prüfen Sie Deposits und sequenzierte Eingaben, Channels und Batches, L1 Origins, Konfigurationsänderungen und Zustandsübergänge anhand kanonischer L1-Daten. Unterscheiden Sie bei Blob-Daten die Verfügbarkeit im Protokollfenster von späterer Archivabrufbarkeit.
4. Ordnen Sie Liveness und Kontrolle zu. Trennen Sie Sequencer, Batcher, Proposer, Challenger, Relayer, Guardian und Upgrade-Befugnis; prüfen Sie Existenz, Verzögerungen und Pausenbedingungen von Forced Inclusion oder Delayed Inbox sowie tatsächlich nutzbare Software für gewöhnliche Nutzer.
5. Prüfen Sie den bereitgestellten Fault-Proof-Pfad. Erfassen Sie respektierten Spieltyp, Proposer- und Challenger-Berechtigungen, Bonds, absoluten Prestate, Proof-Programm und VM, Preimage Oracle, Claim-Tiefe, Uhren und Verlängerungen, Auflösungsregeln, Blacklist- oder Pausenrechte und Upgrade-Verzögerung. Übertragen Sie OP-Stack-Mechanik nicht auf Arbitrum oder andere Rollups.
6. Verfolgen Sie Auszahlungen und Wirtschaftlichkeit getrennt. Folgen Sie L2-Initiierung, L1-Proof, Claim- oder Spielabhängigkeit, Reife- und Finalitätsfrist, erneutem Proof, Portal-Prüfungen und L1-Ausführung. Ein Fast Exit ist eine bepreiste Liquiditäts- oder Kredittransaktion mit eigener Gegenpartei, keine verkürzte kanonische Anfechtungsfrist.
7. Stimmen Sie fortlaufend ab. Vergleichen Sie Unsafe-, Safe- und Finalized-Blockhashes, L1-Batchtransaktionen, State Claims, Spielergebnisse, Bridge-Nachrichten, Belege, Token-Kontrakte und Endsalden. Öffnen Sie die Analyse nach L1- oder L2-Reorg, fehlendem Batch, Streit, Pause, Vertragsupgrade oder DA-Migration erneut.
## Durchgerechnete Beispiele
- **Ableitungs-Payload.** Ein Batch enthält `10,000` Transaktionen, `1,200 KB` rohe Protokolleingaben und `300 KB` nach Kompression. Das Verhältnis beträgt `1,200 / 300 = 4.0x`, die Reduktion `1 - 300 / 1,200 = 75%` und der dezimale Durchschnitt `300,000 / 10,000 = 30 bytes/tx`. Dies beschreibt nur den codierten Input-Payload, nicht L1-Gas, Ausführungskorrektheit, Zustandsgröße oder Archivgarantien.
- **Deckungsbeitrag vor ausgelassenen Kosten.** Nutzer zahlen `2.4 ETH`; gemessene L2-Ausführung kostet `0.3 ETH`; L1-DA kostet `1.2 ETH`. Der Rest beträgt `2.4 - 0.3 - 1.2 = 0.9 ETH` beziehungsweise `0.9 / 10,000 = 0.00009 ETH/tx`. Das ist kein Nettogewinn, da Betreiberinfrastruktur, L1-Ausführung, Proof-Spiele, Erstattungen, Kapital, Ausfälle und Steuern fehlen.
- **Streitlokalisierung.** Eine didaktische Ausführungsspur hat `2^20 = 1,048,576` Schritte. Ideale binäre Eingrenzung benötigt `log2(2^20) = 20` Entscheidungen für einen Einzelschritt. Hätte jede Lehrrunde ein separates Maximum von `3-hour`, ergäbe sich naiv seriell `20 * 3 = 60 hours`; reale Protokolle verwenden eigene Chess Clocks, Parallelität, Verlängerungen und Transaktionsabläufe.
- **Auszahlungsfristen und schnelle Liquidität.** Ein Lehr-Batch erreicht L1 nach `10 minutes`, ein anerkannter Claim folgt nach weiteren `30 minutes`, eine hypothetische Anfechtungsfrist dauert `7 days` und das abschließende Relay `2 hours`. Insgesamt sind es `10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes`. Eine Liquiditäts-Bridge zahlt `4.97 ETH` auf einen `5 ETH`-Claim vor und verlangt `0.03 ETH`, also `0.03 / 5 = 0.6%`; der kanonische Claim bleibt seinen ursprünglichen Fristen und Risiken ausgesetzt.
## Risiken
- Falsche L1, L2, Chain-IDs, Rollup-Konfiguration oder Vertragsbereitstellung.
- Unsafe Sequencer-Beleg als safe oder final behandeln.
- Sequencer-Äquivokation, Zensur, Umsortierung oder Ausfall.
- Verzögerte, fehlende, fehlerhafte oder ungültige L1-Batchveröffentlichung.
- Nicht verfügbare oder nicht archivierte Blob- oder alternative DA-Daten.
- Abweichung von Ableitungsclient, Konfiguration oder Fork.
- L1-Reorg macht zuvor sichere Ableitungseingaben ungültig.
- Ausfall von Batcher, State Proposer oder Proof-Teilnehmer.
- Forced-Inclusion- oder Delayed-Inbox-Pfad fehlt, ist pausiert oder missverstanden.
- Fault Proofs nicht bereitgestellt, inaktiv oder falschem Spieltyp zugeordnet.
- Berechtigte oder allowlist-basierte Proposer- oder Challenger-Rollen.
- Challenger offline, zensiert, unterfinanziert oder nach Fristablauf.
- Fehler in Proof-Programm, VM, absolutem Prestate, Oracle oder Verifier.
- Fehler bei Uhr, Verlängerung, Claim-Position, Bond oder Auflösungsbuchung.
- Eingriff durch Guardian, Security Council, Pause oder Blacklist.
- Sofortiges Upgrade, kurzer Timelock oder kompromittierte Admin-Schlüssel.
- Schwachstelle in kanonischer Bridge, Messenger, Replay oder Asset-Zuordnung.
- Fehler bei Auszahlungs-Proof, Reife, erneutem Proof, Finalisierung oder Relay.
- Liquiditäts-, Preis-, Routing-, Insolvenz- oder Gegenparteirisiko des Fast Exit.
- Verwechslung von L1-Finalität, abgeleiteter L2-Finalität, Claim-Auflösung und Asset-Eingang.
## Häufige Irrtümer
- Optimistic bedeutet bedingungsloses Vertrauen in das angezeigte Sequencer-Ergebnis.
- Ein State Root allein liefert Datenverfügbarkeit und unabhängige Ableitung.
- Jedes Optimistic Rollup hat aktive erlaubnisfreie Fault Proofs und eine universelle Sieben-Tage-Frist.
- Ein Safe oder Finalized L2 Block bedeutet, dass seine L2-zu-L1-Auszahlung bereits ausführbar ist.
- Eine schnelle Bridge verkürzt die kanonische Anfechtungsfrist oder trägt nur Rollup-Risiko.
## Verwandte Themen
- [Fault Proofs](/de/crypto/fraud-proof/)
- [Datenverfügbarkeit](/de/crypto/data-availability/)
- [Rollups](/de/crypto/rollup/)
## Quellen
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (abgerufen: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (abgerufen: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (abgerufen: 2026-08-13)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (abgerufen: 2026-08-13)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (abgerufen: 2026-08-13)
- [Stage 1 Roles and Requirements](https://specs.optimism.io/protocol/stage-1.html) - OP Stack Specification (abgerufen: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (abgerufen: 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/optimistic-rollup/index.mdx