Zum Inhalt springen
Financial Context Wiki

Fault Proof (Fehlernachweis)

Deployment-sensitiver Leitfaden zu optimistischen Fault Proofs, strittigen Claims, Trace-Bisektion, Einzelschrittprüfung, Uhren, Bonds, Datenverfügbarkeit, Auszahlungsfinalität und operativer Verifikation.

Aktualisiert

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

Direkte Antwort

Ein Fault Proof, oft Fraud Proof genannt, ist ein Protokollverfahren zur Anfechtung eines optimistischen Claims über Berechnung oder Zustand. Der Claimant beweist nicht jeden Übergang vor Annahme. Ein berechtigter Challenger kann innerhalb definierter Uhren einen widersprechenden Trace vorlegen; der Settlement-Vertrag entscheidet mit einem festgelegten Verifier. Viele interaktive Designs grenzen einen langen Trace wiederholt auf eine strittige Instruktion ein und führen diesen Basisfall onchain aus.

Der Name beweist weder Permissionlessness noch Verfügbarkeit oder Sicherheit. Erforderlich sind exakte Ableitungsdaten, mindestens ein korrekter Challenger, rechtzeitiger Settlement-Zugang und Gas, korrekte Programme und Verträge sowie Governance, die das Ergebnis nicht umgehen kann. Ein Claim, der sein Spiel übersteht, kann nach den Deployment-Regeln eine Auszahlung autorisieren; er beweist nicht rückwirkend jede L2-Transaktion, Frontend-Aussage oder wirtschaftliche Folge.

1
Sequenzieren

Der Sequencer ordnet L2-Transaktionen und veröffentlicht Transaktionsdaten oder Commitments.

Funktionsweise

  1. Deployment fixieren: L1-/L2-IDs, Rollup- und Proof-Version, Blockhashes, Factory, Portal oder Bridge, Proof-Programm, VM, Spieltyp, Implementierungen und Admins, Berechtigungen, Bonds, Tiefe, Uhren, Fristen, Pause und Finalität. fraud proof ist keine rollupübergreifende Spezifikation.
  2. Claim aus authentisierten Eingaben rekonstruieren: Anchor State, L1-Head, strittigen Block oder Output Root, Batch- und Blobdaten, Konfiguration, Vorzustand, Auszahlungswurzel und Ableitungsregeln erfassen. Eine State Root reicht nicht; fehlende Daten können einen offenen Challenge-Pfad vereiteln.
  3. Prüfen, ob das Spiel erstellt wurde und das Zielobjekt beeinflusst. Root Claim, Claimant, Block und Zeit, Spieltyp, respektierten oder gesperrten Status, Bond, Berechtigung und Portalregel kontrollieren. Pending Claim, Spielergebnis und auszahlungsfähigen Output trennen.
  4. Mit unabhängigem Node und Proof-System re-exekutieren. Ehrlichen Trace vergleichen und Preimages, Witnesses und Versionen sichern. Im interaktiven Spiel das richtige Intervall attackieren oder verteidigen, bis eine Instruktion isoliert ist, dann den Basis-Witness an den onchain VM-Verifier senden.
  5. Teamuhren und Transaktionen verfolgen: Restzeit, Extensions, L1-Inklusion und Reorgs, Calldata, Gas, Ersetzungen, Bonds, parallele Claims und Antwortpflicht. Es gibt nicht zwingend einen Countdown; ein ehrliches Ergebnis kann durch Fristversäumnis oder Zensur verlieren.
  6. Auflösung auf Folgen abbilden: gekonterte Claims, Gewinner, Bond- und Kostenverteilung, Ausschluss ungültiger Outputs und nötige Neubildung abhängiger Outputs, Proofs oder Auszahlungen. Slashing ist Anreiz, kein vollständiger Schadenersatz.
  7. Finalität und Auszahlungen getrennt abgleichen: Auflösung, Reife- und Nachfristen, respektierten Spieltyp, Blacklist und Pause, Inklusionsnachweis, Finalisierungsbeleg und L1-Finalität prüfen. Daten archivieren und Challenge, Forced Inclusion, erneuten Proof und Notausstieg üben.

Durchgerechnete Beispiele

  • Trace-Bisektion. Ein Lehr-Trace hat 1,048,576 = 2^20 instructions. Halbiert jede unbestrittene Runde das Intervall, isolieren 20 bisections eine Instruktion, denn 2^20 / 2^20 = 1. Reale Spiele können mehrere Traces, DAG-Zweige und Zusatzschritte haben; dies ist keine Deployment-Rundenzahl.
  • Unabhängige Spieluhren. Hypothetisch erhält jedes Team 84 hours. Der Defender verbraucht 30 hours, der Challenger 22 hours; übrig bleiben 54 hours und 62 hours. Die verstrichene Zeit ist nicht einfach 84 hours: Nur die jeweilige Uhr läuft; Extensions, Inklusionsverzögerungen und parallele Claims ändern Fristen.
  • Bond- und Gas-Ledger. Nach einer ausdrücklich hypothetischen Regel trägt eine ungültige Root 2 ETH Bond. Der Gewinner hinterlegte 0.5 ETH, erhält den Betrag plus 1.4 ETH Belohnung zurück und zahlte 0.08 ETH L1-Gas; 0.6 ETH gehen an die Treasury. Nettogewinn: 1.4 - 0.08 = 1.32 ETH; die 0.5 ETH sind Kapital, kein Gewinn, und 1.4 + 0.6 = 2 ETH. Empfänger und Freeloader-Regeln sind vertragsspezifisch.
  • Auszahlungsuhren. Proof am 2026-08-01 12:00 UTC, Reife 7 days, Spielauflösung 2026-08-06 18:00 UTC, Air Gap 1 day. Die Schranken enden 2026-08-08 12:00 UTC und 2026-08-07 18:00 UTC; frühester gemeinsamer Zeitpunkt ist 2026-08-08 12:00 UTC. Mit 20 minutes L1-Finalität ergibt sich 2026-08-08 12:20 UTC, sofern keine Pause, Blacklist, Re-Proof oder Reorg eintritt.

Risiken

  • Falsche L1, L2, Deployment-, Spiel- oder Vertragsversion prüfen.
  • Von veraltetem, nichtkanonischem oder falschem Anchor rekonstruieren.
  • Fehlende Batch-, Blob-, Preimage-, Witness- oder Konfigurationsdaten.
  • Aus einem Commitment vollständige Datenverfügbarkeit folgern.
  • Abweichender ehrlicher Trace durch Clientfehler.
  • Fehler in Proof-Programm, VM, Preimage-Orakel oder Schritt-Verifier.
  • Permissionierter oder ausgefallener Proposer, Challenger oder Spielzugang.
  • Kein ehrlicher Watcher eröffnet rechtzeitig eine Dispute.
  • Zensur, L1-Stau, Reorg oder Gas-Spike verhindert einen Zug.
  • Uhren, Extensions, Tiefe oder Inklusionszeit falsch lesen.
  • Falschen Claim, Bereich, Position oder Schritt bearbeiten.
  • Bonds oder Betriebskapital machen Teilnahme unpraktisch.
  • Bondverteilung, Freeloader oder Anreize weichen von Annahmen ab.
  • Mehrere Spiele, doppelte Claims oder Implementierungen kollidieren.
  • Governance ändert Spieltyp, Verifier, Schwelle oder Verzögerung.
  • Guardian-Pause oder Blacklist blockiert gültige Auszahlungen.
  • Spielauflösung mit sofortiger Auszahlungsfinalität verwechseln.
  • Gegen invalidiertes Spiel beweisen und nicht erneut beweisen.
  • Ausschluss eines Outputs als Reparatur aller Folgeeffekte ansehen.
  • Ein Rollup-Modell auf andere Systeme übertragen.

Häufige Irrtümer

  • Ein unangefochtener optimistischer Claim ist kryptografisch bewiesen.
  • Jeder kann jedes Deployment ohne Rechte, Kapital oder Infrastruktur anfechten.
  • Fault Proofs funktionieren ohne verfügbare Ableitungsdaten.
  • Ein Sieg finalisiert sofort alle Auszahlungen und ersetzt alle Schäden.
  • Sieben Tage, Binärspiel und ein ehrlicher Beobachter gelten universell.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...