Zum Inhalt springen
Financial Context Wiki

Blockchain-Finalität: Nachweise, Annahmen und Abwicklungsebenen

Finalität ist die protokollspezifische Zusicherung, dass eine Entscheidung ohne Verletzung der Sicherheitsannahmen oder außergewöhnliche Wiederherstellung nicht ersetzt wird. Gültigkeit, Fork Choice, Finalitätsnachweis, Fehlergrenzen, Ebenen und Anwendungsabwicklung sind getrennt zu prüfen.

Aktualisiert

Nur zur Protokollanalyse und Bildung. Bezeichnungen wie „bestätigt“, „sicher“, „committed“ oder „finalisiert“ sind nur zusammen mit Chain, Regelsatz, Nachweis, Fehlerannahmen, Ebene und Anwendungsrichtlinie aussagekräftig.

Direkte Antwort

Finalität ist die protokollspezifische Zusicherung, dass eine akzeptierte Entscheidung wie ein Block, Checkpoint oder State Commitment nicht ersetzt wird, ohne die genannten Sicherheitsannahmen zu verletzen oder ein außergewöhnliches Wiederherstellungsverfahren einzusetzen. Sie ist weder eine physische Eigenschaft der Transaktionsbytes noch bloß „die Transaktion war erfolgreich“. Jede Aussage muss Objekt, Netzwerk, Protokollversion, Nachweis, Fehler- und Zeitmodell, vertrauenswürdigen Ausgangspunkt und Beobachter nennen.

Gültigkeit, Kanonizität und Finalität sind verschieden. Ein gültiger Block erfüllt Zustandsübergangs- und Autorisierungsregeln. Fork Choice wählt aus gültigen Kandidaten den aktuellen kanonischen Head. Finalisierung wendet ein zusätzliches Prädikat, etwa ein Commit-Zertifikat oder einen finalisierten Checkpoint, auf einen Vorfahren dieses Heads an. Eine Transaktion kann in einem später verworfenen gültigen Block erfolgreich sein; ein Head kann kanonisch, aber unfinalisiert sein; und ein finalisiertes Ereignis der Quell-Chain kann in Bridge, Börse oder Anwendung scheitern.

Proof-of-Work bietet meist probabilistische Abwicklung statt eines ausdrücklichen Finalitätsbits: Je mehr gültige kumulierte Arbeit auf einem Block aufbaut, desto unwahrscheinlicher und teurer wird sein Ersatz unter den genannten Hashrate- und Netzannahmen. Ein BFT-Protokoll kann bedingte deterministische Finalität bieten: Nach einem gültigen Commit-Zertifikat können zwei widersprüchliche Entscheidungen nicht beide committed werden, solange das fehlerhafte Stimmgewicht unter der bewiesenen Grenze bleibt. PoS-Finalität kann zudem rechenschaftspflichtig oder ökonomisch sein, weil widersprüchliche Stimmen slashbares Gewicht erkennen lassen. Diese Begriffe beschreiben unterschiedliche Nachweise.

Kein Protokoll macht Geschichte absolut unveränderlich. Katastrophaler Schlüsselverlust, überschrittene Fehlergrenzen, Clientfehler, von Implementierungen akzeptierte ungültige Übergänge, Governance-Eingriffe oder soziale Wiederherstellung können die Modellgrenze überschreiten. „Finalisiert“ sollte deshalb heißen: „Der gewöhnliche Reorganisationspfad des Protokolls kann diese Entscheidung unter diesen Annahmen nicht ersetzen.“ Außergewöhnliche Wiederherstellung und ihre Autorität sind getrennt zu dokumentieren.

Finalität analysieren

  1. Objekt und Umfang benennen. Transaktion, Block, Checkpoint, State Root, Cross-Chain-Nachricht oder Auszahlung bestimmen; Chain, Netzwerk, Ebene, Protokollversion, Höhe oder Slot, Blockhash und vertrauenswürdigen Checkpoint festhalten.
  2. Gültigkeit vor Status prüfen. Den relevanten Zustandsübergang und die Abstammung erneut ausführen oder anderweitig validieren. Quorum, Work-Score oder UI-Abzeichen können nach den tatsächlichen Regeln kein ungültiges Objekt finalisieren.
  3. Head-Auswahl und Finalisierung trennen. Fork Choice und aktuellen kanonischen Pfad rekonstruieren, dann den finalisierten oder committed Vorfahren ermitteln. Festhalten, ob der Status nur beobachtet, bestätigt, gerechtfertigt, sicher, committed oder finalisiert ist.
  4. Nachweis reproduzieren. Bei PoW Header, Target und kumulierte Chainwork über dem Block prüfen. Bei Abstimmungsprotokollen Berechtigung, Gewichtssnapshot, Nachrichtendomäne, Quelle und Ziel, Höhe, Runde, Quorumsungleichung, Signaturen, Locks und Zertifikatsabstammung prüfen.
  5. Safety- und Liveness-Annahmen angeben. Byzantinisches oder offline befindliches Gewicht, Synchronität, Verzögerung, Äquivokation, Schlüsselverlust, Client-Korrelation, Mitgliederwechsel, Slashing-Verfügbarkeit und Verhalten bei Stillstand nennen. Ein Halt kann Safety wahren und Liveness verlieren.
  6. Jede Abwicklungsebene abbilden. Sequencer-Eingang, L2-Ausführung, Datenveröffentlichung, L1-Aufnahme, L1-Finalität, Beweis- oder Streitabschluss, Bridge-Ausführung, Börsengutschrift und App-Aktion verfolgen. Ähnliche Labels auf verschiedenen Ebenen müssen nicht dasselbe Prädikat bezeichnen.
  7. Anwendungsrichtlinie festlegen und überwachen. Nach Wert und Folgen zulässige Nachweise definieren, unabhängige Nodes abfragen, Reorganisationen und Konfliktalarme behandeln, irreversible Folgeaktionen bei gebrochenen Annahmen stoppen und Wiederherstellungsbefugte dokumentieren.

Die Bestätigungszahl ist eine Beobachtung, keine universelle Finalitätsregel. In Bitcoin Core hängt confirmations von der Position eines Blocks in der aktuellen aktiven Chain ab, während chainwork die kumulierte erwartete Arbeit angibt. Bei Ethereum sind LMD-GHOST-Head-Auswahl und Casper-FFG-Rechtfertigung und -Finalisierung getrennte Zustandsübergänge. Bei CometBFT erfordert ein Commit mehr als zwei Drittel der Stimmkraft als Precommit für denselben Block auf derselben Höhe und Runde. Jeder Status ist im eigenen Protokoll auszulegen.

Rechenbeispiele

1. Probabilistische Proof-of-Work-Abwicklung

Das Bitcoin-Whitepaper modelliert einen Angreifer mit Hashrate-Anteil q=0.10, der nach einem Vorsprung der ehrlichen Chain von z=6 aufholen will. Unter den Annahmen unabhängiger Hashversuche und einer Poisson-Verteilung beträgt die berechnete Aufholwahrscheinlichkeit:

P=0.0002428 = 0.02428%

Das Ergebnis ist klein, nicht null und keine allgemeine „Sechs-Bestätigungen-Garantie“. Die Praxis muss Transaktionswert, beobachtete Chainwork, Hashrate-Konzentration, Eclipse- oder Partitionsrisiko, Gebührenanreize und die Glaubwürdigkeit eines konstanten Angreiferanteils berücksichtigen.

2. Rechtfertigung und Finalisierung bei Ethereum

Betrachtet wird ein vereinfachter Pfad aufeinanderfolgender Checkpoints mit aktiver effektiver Gesamtbalance 100. Stimmen von 67/100, die den gerechtfertigten Checkpoint C_0 mit Ziel C_1 verbinden, erreichen mindestens zwei Drittel und rechtfertigen C_1. Ein späterer qualifizierender Link von 67/100 von C_1 zum direkten Kind C_2 kann C_1 nach der anwendbaren Casper-FFG-Regel finalisieren.

Der Head kann über C_2 hinausreichen, während der neuere Teil unfinalisiert bleibt. Ist Balance 34 offline, bleiben nur 66; unmittelbare Finalisierung stockt, obwohl Fork Choice und Blockproduktion weiterlaufen können. Nach mehr als vier Epochen ohne Finalität bestraft Ethereums Inactivity Leak Nichtteilnahme, damit eine aktive Supermehrheit schließlich Finalität wiederherstellen kann.

3. Safety und Liveness bei CometBFT

Das Gesamtstimmgewicht sei 100; ein Commit verlange >2/3 Precommits für denselben Block in einer Höhe und Runde. Ganzzahliges Gewicht 67 committed. Zwei Commit-Mengen mit Gewicht 67 überschneiden sich in mindestens 67 + 67 - 100 = 34. Liegt byzantinisches Gewicht unter einem Drittel und befolgen ehrliche Validatoren die Locking-Regeln, können keine zwei widersprüchlichen Commits entstehen.

Ist Gewicht 34 nicht verfügbar, können nur 66 abstimmen und kein Commit entsteht. Das Protokoll kann Safety wahren, während Finalisierung stoppt. „Kein widersprüchlicher finalisierter Block“ und „neue Blöcke werden weiter finalisiert“ sind verschiedene Garantien.

4. OP-Stack-Status und Auszahlungsfristen

Ein OP-Stack-Sequencer kann einen L2-Block zunächst als unsafe veröffentlichen. Kann er vollständig aus Daten der aktuell kanonischen L1-Chain abgeleitet werden, kann der Rollup-Node ihn als safe markieren. Erhalten die entsprechenden L1-Eingaben ein L1-Finalitätssignal, kann der abgeleitete L2-Block finalized werden.

Dieser Status betrifft die Ableitung aus finalisierten Eingaben. Ein Optimistic-Rollup-Output oder eine L2-zu-L1-Auszahlung hat einen eigenen Beweis- und Streitprozess und kann erst nach erfüllter Challenge-Bedingung „finalisiert“ heißen. Wer Sequencer-Bestätigung, L1-Datenaufnahme, L1-Konsensfinalität und Auszahlung auf einen Zeitpunkt reduziert, kann Werte zu früh freigeben.

Risiken und Prüffehler

Definition und Nachweis

  • Jede erfolgreiche Ausführung, Quittung, Bestätigung, jeden Checkpoint oder UI-Status „final“ nennen.
  • Chain, Netzwerk, Version, Objekthash, Höhe oder Slot, Ebene und Beobachter auslassen.
  • Den aktuellen Fork-Choice-Head als finalisierten Vorfahren behandeln oder annehmen, Finalisierung wähle den neuesten Head.
  • Blöcke oder Minuten zählen, ohne Abstammung, Targets, Arbeit, Stimmen oder Zertifikate zu prüfen.
  • „Zwei Bestätigungen“ oder „zehn Minuten Finalität“ zwischen Protokollen mit anderen Nachweisen vergleichen.
  • Signaturen ohne Berechtigung, Gewicht, Domäne, Quelle, Ziel, Höhe und Runde prüfen.
  • Ökonomische Kosten, slashbaren Nachweis und tatsächliche Sanktion als dieselbe Garantie behandeln.
  • Probabilistisches Risiko als null oder bedingte deterministische Safety als unbedingte Unumkehrbarkeit darstellen.

Protokoll- und Betriebsfehler

  • Byzantinische Grenze überschreiten, für Liveness nötiges Online-Gewicht verlieren oder eine Partition verbergen.
  • Implementierungen bei Gültigkeit, Fork Choice, Checkpoint-Übergang, Quorumsrundung oder Zertifikatsabstammung abweichen lassen.
  • Veraltete, wiederholte oder netzwerkfremde Stimmen, Commits, Checkpoints oder Weak-Subjectivity-Daten akzeptieren.
  • Schlüssel, Stake, Hashrate, Clients, Relays, Clouds oder RPC-Sichten hinter nominell getrennten Identitäten konzentrieren.
  • Annehmen, Inactivity Leak, Timeout oder View Change stelle Fortschritt sofort und folgenlos wieder her.
  • Finalitätsverzug, widersprüchliche Zertifikate, tiefe Reorganisation, Äquivokation oder abweichende finalisierte Roots nicht alarmieren.
  • Notfall-Governance oder soziale Wiederherstellung ohne Autorität, Koordination, Clientrelease und betroffene Garantien dokumentieren.

Ebenen- und Anwendungsfehler

  • Sequencer-Aufnahme zugleich als L2-Safety, L1-Veröffentlichung, L1-Finalität, Beweisannahme und Auszahlungsabschluss behandeln.
  • Bridge-Assets freigeben, bevor Quellereignis und eigener Verifikationspfad die Richtlinie erfüllen.
  • Einzahlungen oder irreversible Trades nach dem Status nur eines RPC-Anbieters ohne unabhängigen Abgleich ausführen.
  • Annehmen, Chain-Finalität garantiere Oracle-Wahrheit, Contract-Korrektheit, Datenverfügbarkeit, Börsensolvenz oder rechtliche Abwicklung.
  • Dieselbe feste Bestätigungsschwelle für jeden Wert, Gegner, Angriffsanreiz und Wiederherstellungspreis anwenden.

Häufige Missverständnisse

  • Eine erfolgreiche Transaktion ist final. Erfolg beschreibt nur einen Zustandsübergang in einer Kandidatenhistorie; Kanonizität und Finalität benötigen weitere Nachweise.
  • Mehr Bestätigungen machen das PoW-Risiko exakt null. Die Modellwahrscheinlichkeit kann stark fallen, bleibt aber annahmeabhängig und wird nicht logisch unmöglich.
  • Zwei Drittel bedeuten immer Finalität. Ungleichung, Nachrichtentyp, Gewichtssnapshot, Höhe, Runde, Quell-Ziel-Beziehung und Locking-Regel sind protokollspezifisch.
  • Finalität garantiert weiteren Fortschritt. Safety kann erhalten bleiben, während mangelnde Teilnahme oder Verbindung neue Finalisierung verhindert.
  • L1-Finalität schließt jede L2- oder Bridge-Aktion ab. Datenableitung, Gültigkeits- oder Betrugsbeweis, Challenge-Frist und Zielausführung können eigene Fristen und Fehlerpfade haben.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...