Zum Inhalt springen
Financial Context Wiki

Was tun, wenn ein L2-Sequenzer ausfällt?

Praktischer Reaktionsplan bei einem L2-Sequenzer-Ausfall: Störung prüfen, doppelte Transaktionen vermeiden, den L1-Ersatzweg des Rollups prüfen und Erholungs- sowie Liquidationsrisiken beachten.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Behandeln Sie einen Sequenzer-Ausfall als Verlust des normalen L2-Zugangs, nicht als Beweis dafür, dass das Rollup oder Ihre Vermögenswerte ausgefallen sind. Stoppen Sie zeitkritische Aktionen, prüfen Sie den Vorfall über die offizielle Statusseite der Chain sowie unabhängige RPC- oder Explorer-Daten und klären Sie den genauen L1-Ersatzweg dieses Rollups, bevor Sie etwas signieren.

  1. Notieren Sie Chain, Wallet-Adresse, ausstehende Transaktions-Hashes, den zuletzt beobachteten Block und den Zeitpunkt des Ausfalls.
  2. Senden Sie nicht wiederholt neu und erhöhen Sie keine Gebühren, solange der Transaktionsstatus unbekannt ist.
  3. Prüfen Sie, ob sich der unsafe head weiterbewegt, während der safe oder finalized head steht; das kann auf einen Batch-Veröffentlichungsausfall statt auf einen Totalstillstand hindeuten.
  4. Nutzen Sie einen erzwungenen L1-Transaktions- oder Auszahlungsweg nur anhand offizieller Dokumentation und verifizierter Vertragsadressen.
  5. Warten Sie nach der Erholung, bis Rückstau, Oracle-Status, Bridge-Status und anwendungsspezifische Schonfrist normalisiert sind, bevor Sie den Hebel erhöhen oder eine Transaktion als final ansehen.

Funktionsweise

Ein Sequenzer empfängt, ordnet und bestätigt L2-Transaktionen normalerweise schnell und veröffentlicht anschließend die zur Chain-Ableitung nötigen Daten auf der Datenverfügbarkeitsschicht. Ein Downtime-Ausfall kann gewöhnliche RPC-Einreichungen verhindern. Bei einem separaten Veröffentlichungsausfall kann der Sequenzer weiter unsafe Blöcke erzeugen, während die Veröffentlichung auf L1 und damit safe und finalized heads stoppen. Diese Zustände haben unterschiedliche Reorganisations- und Erholungsrisiken.

Der Ersatzweg hängt von der Implementierung ab. Auf OP-Stack-Chains können Nutzer eine L2-Transaktion über das verifizierte OptimismPortal der Chain auf L1 einreichen; das Standard-Sequenzierungsfenster beträgt 12 Stunden, kann aber je Chain abweichen. Arbitrum Nitro nutzt eine L1 Delayed Inbox; das veröffentlichte Design beschreibt die erzwungene Aufnahme nach einer Schwelle von 24 Stunden. Diese Mechanismen sichern eine spätere Aufnahme, keinen sofortigen oder universellen Ausstieg, und benötigen weiterhin L1-Gas sowie die richtigen chain-spezifischen Verträge.

Auch Anwendungen brauchen eigene Kontrollen. Ein Sequenzer-Uptime-Feed kann Downtime melden, ist aber von einem Preis-Feed getrennt. Kredit- und Derivateprotokolle können sensible Vorgänge während des Ausfalls pausieren und eine Schonfrist nach der Erholung erzwingen, damit wartende Oracle-Aktualisierungen und Nutzertransaktionen nicht sofort zu unfairen Liquidationen führen.

Beispiel

Ein Kreditnehmer hat ETH als Sicherheit in einem L2-Kreditprotokoll. Der Sequenzer ist 2 Stunden nicht verfügbar, während ETH um 15% fällt, sodass der Kreditnehmer über den normalen RPC keine Sicherheit nachschießen kann. Das Protokoll erkennt den Ausfall, pausiert Liquidationen und hält sie nach der Erholungsmeldung des Uptime-Feeds während einer konfigurierten Schonfrist von 1 Stunde weiter an.

Der Kreditnehmer notiert den ausstehenden Transaktions-Hash, prüft die offizielle Störungsmeldung und den safe head des Rollups und vertraut keiner Support-Nachricht mit einem Link zum „Entsperren“. Ist eine Aktion weiterhin nötig, folgt er dem offiziellen L1-Weg des Rollups und verifiziert die Portal- oder Inbox-Adresse. Nach der Erholung wartet er, bis erzwungene Transaktion, Preis-Feed und Kontogesundheit in einem safe Block erscheinen, bevor er sich auf das Ergebnis verlässt.

Risiken

  • Liquidationen nach der Erholung: Wartende Transaktionen und Preisaktualisierungen können dicht aufeinander verarbeitet werden; ohne Schonfrist können Nutzer, die während des Ausfalls nicht handeln konnten, sofort liquidiert werden.
  • Reorganisation des unsafe Zustands: Ein RPC kann aktuelle, noch nicht auf L1 veröffentlichte Blöcke anzeigen, die bei Ablauf des Veröffentlichungsfensters reorganisiert werden könnten.
  • Veraltete oder widersprüchliche Signale: Ein laufender Preis-Feed beweist keine Transaktionsfähigkeit, und ein Uptime-Feed beweist nicht, dass ein Preis aktuell ist.
  • Ausführungsrisiko des Zwangswegs: Direkte L1-Aufrufe sind technischer und teurer; falsches Netzwerk, Vertrag, calldata, nonce oder Gaslimit können scheitern oder Mittel festsetzen.
  • Verzögerungen abhängiger Systeme: Bridges, Börsen, Keeper, Indexer und Frontends können sich selbst nach Wiederanlauf des Sequenzers unterschiedlich schnell erholen.

Häufige Irrtümer

  • „Der Sequenzer ist ausgefallen, also sind die Vermögenswerte weg.“ Der von L1 durchgesetzte Rollup-Zustand kann intakt bleiben, obwohl der normale Zugang fehlt.
  • „Jedes Rollup hat dieselbe Verzögerung für die erzwungene Aufnahme.“ Fenster, Verträge und unterstützte Aktionen unterscheiden sich nach Implementierung und Chain-Konfiguration.
  • „Eine erzwungene Transaktion wird sofort ausgeführt.“ Die L1-Einreichung schafft einen Weg zur späteren Aufnahme; Sequenzierungs-, Beweis- oder Auszahlungsverzögerungen bleiben bestehen.
  • „Sobald Blöcke wieder laufen, ist das Liquidationsrisiko vorbei.“ Rückstau, Oracle-Aktualisierungen und Keeper können die Erholungsphase am riskantesten machen.
  • „Ein Statusseiten-Link vom Support ist sicher.“ Prüfen Sie Domain und Vertragsadresse unabhängig und geben Sie niemals Seed-Phrase oder privaten Schlüssel preis.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...