Zum Inhalt springen
Financial Context Wiki

Fork-Choice-Regeln: gültige Zweige, Gewicht und kanonischer Head

Eine Fork-Choice-Regel bildet die validierte lokale Sicht eines Nodes auf einen aktuellen kanonischen Head ab. Kandidatengültigkeit, Abstammung, kumulierte Arbeit oder Stimmgewicht, Checkpoints, Zeit, Gleichstand, Reorganisation und Finalität sind getrennt zu analysieren.

Aktualisiert

Nur zur Protokollanalyse und Bildung. Der aktuelle Head eines Nodes hängt von Netzwerk, Regelversion, validierter lokaler Sicht, Gewichtsnachweis, Checkpoint und Zeit ab; er ist dadurch weder automatisch finalisiert noch für irreversible Anwendungsabwicklung sicher.

Direkte Antwort

Eine Fork-Choice-Regel ist das Protokollverfahren, das die validierte lokale Sicht eines Nodes auf konkurrierende Blöcke und Konsensnachrichten in einen aktuellen kanonischen Head überführt. Die Ausgabe ist vorläufig und beobachterbezogen: Zwei ehrliche Nodes können kurz verschiedene Heads wählen, weil sie andere gültige Blöcke, Stimmen oder Zeitereignisse erhalten haben. Wenn ihre zulässigen Sichten unter den Netzannahmen konvergieren, soll auch die Regel konvergieren.

Fork Choice macht keinen ungültigen Block gültig. Zustandsübergang, Autorisierung, Beweis, Abstammung und Datenverfügbarkeit bestimmen die zulässigen Kandidaten, bevor Gewicht verglichen wird. Der gewählte Head ist auch nicht zwingend finalisiert. Fork Choice bestimmt den jetzt zu erweiternden Zweig; eine Finalitätsregel kann einen älteren Vorfahren mit stärkerem Safety-Nachweis schützen. Den aktuellen Head zu ersetzen kann normal sein, einen finalisierten Checkpoint zu ersetzen überschreitet eine andere Protokollgrenze.

„Längste Chain“ ist keine universelle Formel. Bitcoin wählt die gültige Chain mit der meisten kumulierten erwarteten Proof-of-Work-Arbeit, nicht der rohen Höhe. Ethereums LMD-GHOST beginnt an einem gerechtfertigten Checkpoint, filtert zulässige Zweige und folgt gierig dem Kind mit der größten neuesten attesting balance plus gegebenenfalls Proposer Boost; je Validator zählt nur die neueste zulässige Nachricht. Andere Protokolle können Verfügbarkeitszertifikate, Leader Locks, Runden oder explizite Commit-Zertifikate statt eines dauerhaften Wettbewerbs um den schwersten Zweig verwenden.

Das Ergebnis hängt von exakten Eingaben ab: Chain und Netzwerk, Fork-Version, Vertrauensanker, Zeit oder Slot, bekannte gültige Blöcke, Elternlinks, Work- oder Stimmgewichtssnapshot, neueste Nachrichten, Äquivokationsnachweis, gerechtfertigte und finalisierte Checkpoints, Verfügbarkeit, Proposer-Zeit und deterministische Gleichstandsregeln. Explorer-Badge oder ein RPC sind Beobachtungen eines Node-Ergebnisses, nicht die Regel oder unabhängiger Nachweis der Eingaben.

Eine Fork-Choice-Regel analysieren

  1. Identität und Version fixieren. Chain, Netzwerk, Konsens-Fork, Clientversion, Genesis oder Vertrauensanker, Höhe oder Slot und aktive Regel erfassen. Mainnet-Logik nicht auf Testnet, Sidechain, Rollup oder künftigen Vorschlag übertragen.
  2. Zulässigen Blockgraph bauen. Hashes, Eltern, Konsensbeweise, Übergänge, Payload-Status und nötige Datenverfügbarkeit prüfen. Unbekannte, optimistische, ungültige und beschnittene Nodes markieren; Gewicht rettet keinen ungültigen Zweig.
  3. Abstammung und Grenzen rekonstruieren. Gemeinsamen Vorfahren ermitteln und prüfen, welche Kandidaten von geforderten Checkpoints, Locks oder Zertifikaten abstammen. Beobachteten Rohbaum vom gefilterten Regelbaum trennen.
  4. Jede Gewichtseingabe reproduzieren. Bei PoW Targets dekodieren und Blockbeweis zur kumulierten Chainwork addieren. Bei Stimmen Identität, aktive effektive Balance oder Gewicht, Domäne, Ziel-Root, Slot oder Epoche, Latest-Message-Ersatz, Äquivokationsbehandlung und temporären Boost prüfen.
  5. Auswahl und Tie-Break exakt ausführen. Vorgeschriebene Rekursion oder Comparator an jedem Zweig mit Protokollrundung und deterministischer Ordnung anwenden. Festhalten, ob Gleichgewicht lokale vorläufige Präferenz erlaubt; ein Tie ist kein finaler Konsens.
  6. Head-Wechsel abgleichen. Bei neuem Sieger getrennte und angehängte Blöcke bestimmen, Zustand zurückrollen und wiederholen, Receipts, Logs und Mempool abgleichen und Reorg-Tiefe vom gemeinsamen Vorfahren berechnen. Head, safe, justified, committed und finalized trennen.
  7. Deployment stressen und überwachen. Verzögerte oder zurückgehaltene Blöcke, Partitionen, alte Stimmen, Äquivokation, Balancing, Proposer-Zeit, Clientabweichung, schwache Checkpoints und fehlende Daten testen. Unabhängige Nodes vergleichen und vor irreversiblen Aktionen unerwartete Head-Divergenz, tiefe Reorgs oder Konflikte mit finalisiertem Zustand alarmieren.

Bitcoin Core ordnet Kandidaten zuerst nach nChainWork; bei gleicher Arbeit folgen früheste aktivierbare Sequenz und interner Fallback. Das RPC-Feld blocks ist die Höhe der Most-Work-Chain, die vollständig validiert wurde, und bestblockhash bezeichnet ihren Tip. In Ethereums aktueller Spezifikation startet get_head(store) bei justified_checkpoint, durchläuft einen gefilterten Baum und wählt je Schritt das Kind mit maximalem (get_weight(store, child), child.root). Das sind protokoll- und versionsspezifische Details, keine allgemeine Konsensdefinition.

Rechenbeispiele

1. Bitcoin-Wechsel nach kumulierter Arbeit

Zwei gültige Zweige teilen Vorfahren C. Die Tips haben chainwork(A)=240 und chainwork(B)=235; der Node wählt A, auch wenn eine grobe Höhenansicht ähnlich aussieht. Ein neuer gültiger Block fügt B Arbeit 10 hinzu:

chainwork(B') = 235 + 10 = 245

Da 245 > 240, ist B der Most-Work-Kandidat. Der Node trennt A nach C, verbindet B bis B' und gleicht Transaktionen ab. Rohe Blockzahl reicht bei verschiedenen Targets nicht; gleiche Arbeit ist ein temporärer Gleichstand, kein Finalitätsnachweis.

2. Gierig schwerster beobachteter Teilbaum

Verwendet wird ein vereinfachter LMD-GHOST-Baum ab gerechtfertigtem Checkpoint J. Seine Kinder sind A und B. Neueste zulässige Nachrichten geben As gesamtem Teilbaum Gewicht 61, Bs Teilbaum 39; der erste Schritt wählt A. As Kinder A_1 und A_2 haben Teilbaumgewichte 34 und 27; danach folgt A_1.

Der Head entsteht durch wiederholtes Wählen des schwersten Kindes, nicht durch Zweiglänge oder das Blatt mit der größten isolierten Direktstimme. Die Produktionsregel enthält außerdem Viability-Filter, Balancesnapshot, Äquivokationsbehandlung, Proposer-Zeit und Tie-Breaks, die dieser Lehrbaum auslässt.

3. Ersatz der neuesten Nachricht

Neueste zulässige Nachrichten geben A zunächst Gewicht 55 und B 45. Ein Validator mit Gewicht 20 sendet später eine neuere zulässige Nachricht für einen B-Nachfahren. Latest-Message-Buchführung entfernt die alte Unterstützung von A und fügt sie B hinzu:

A: 55 - 20 = 35; B: 45 + 20 = 65

Das Gewicht zählt einmal, nicht auf beiden Zweigen; der Pfad kann wechseln. Widersprüchliches Stimmen ist damit nicht erlaubt: Gültiger Attester-Slashing-Nachweis lässt den aktuellen Ethereum Store den äquivokierenden Validator verfolgen und sein Gewicht aus normalem Attestation-Scoring ausschließen.

4. Checkpoint-Filter und Proposer Boost

Ein Node beobachte Rohgewicht 70 auf einem Zweig, der seinem finalisierten Checkpoint widerspricht, und 30 auf einem zulässigen Nachfahren. Der Konfliktzweig wird vor der Head-Auswahl ausgeschlossen; rohe Mehrheit kann die Checkpoint-Grenze nicht durch gewöhnlichen Fork Choice überschreiben.

Zwei zulässige Kinder im aktuellen Slot haben Attestation-Gewichte 35 und 50. In der zitierten Ethereum-Konfiguration beträgt ein rechtzeitiger Boost 40% des Gewichts eines Komitees, nicht 40 Prozent des Gesamtstakes. Bei Komitee-Gewicht 100 und Boost für das 35er-Kind wird dessen Score 35 + 40 = 75 und schlägt 50. Der Boost ist temporär und forkspezifisch, weder zusätzliche Validatorstimme noch Finalität.

Risiken und Prüffehler

Kandidatenmenge und Nachweis

  • Zweiggewicht vergleichen, bevor Eltern, Übergänge, Beweise, Payload-Status oder Daten geprüft sind.
  • Unbekannte oder optimistische Ausführung, fehlende Daten oder Header-only-Sicht als voll validiert behandeln.
  • Höhe, Timestamp, Transaktionszahl, Fees oder Explorer-Popularität statt vorgeschriebenem Gewicht verwenden.
  • Angezeigte Difficulty addieren, ohne Blockbeweis und Chainwork unter korrekten Targets zu reproduzieren.
  • Alle historischen Stimmen statt neuester zulässiger Nachricht je Validator mit richtigem Snapshot zählen.
  • Domäne, Root, Slot, Epoche, Rechtzeitigkeit, Signatur, Äquivokation und Slashing-Nachweis ignorieren.
  • Rohzweige vergleichen, die Checkpoint-, Lock-, Zertifikats- oder Verfügbarkeitsfilter ausschließen.
  • Künftige Spezifikation, fremden Netzwerkparameter oder Optimierung als geltendes Konsensrecht anwenden.

Auswahl- und Betriebsfehler

  • Bitcoin als rohe „größte Höhe“ oder Ethereum als einfache Zweidrittel-Head-Abstimmung beschreiben.
  • Gierige Teilbaumrekursion durch globalen Blatt-Score ersetzen oder Boost, Rundung und Root-Tie-Break auslassen.
  • Annehmen, Nodes mit anderer Ankunftsfolge, Uhr oder Nachrichtensicht meldeten sofort denselben Head.
  • Zustand, Receipts, Logs, Indizes und Mempool bei Reorg nicht korrekt trennen und wiederholen.
  • Clients bei Gültigkeit, Checkpoint-Viability, neuesten Nachrichten, Zeit oder Tie-Breaks abweichen lassen.
  • Balancing, Withholding, Äquivokation, Partition, Eclipse, verzögerte Stimmen und Proposer-Reorg übersehen.
  • Einem RPC, Explorer, Relay, Clienttyp, Cloud- oder Validatorbetreiber als unabhängiger Konsenssicht vertrauen.

Finalitäts- und Anwendungsfehler

  • Den gewählten Head ohne separaten Finalitätsnachweis finalisiert, unumkehrbar oder sicher nennen.
  • Einzahlungen, Bridge-Nachrichten oder irreversible Trades auf transientem Head ohne wertabhängige Richtlinie freigeben.
  • Annehmen, finalisierter Vorfahr garantiere Richtigkeit oder Verfügbarkeit jedes neueren Heads, Payloads, Oracles oder App-Ergebnisses.
  • Feste Bestätigungszahl für Chains mit anderen Work-, Vote-, Checkpoint- und Recovery-Modellen verwenden.
  • Notfall-Checkpoints, Weak-Subjectivity-Anker oder soziale Wiederherstellung als gewöhnliche Inputs ohne Vertrauensgrenze behandeln.

Häufige Missverständnisse

  • Der längste Zweig gewinnt immer. Protokolle können kumulierte Arbeit, gewichtete neueste Nachrichten, Zertifikate oder andere Scores vergleichen; rohe Höhe ist nicht universell.
  • Der schwerste beobachtete Zweig ist automatisch gültig. Gültigkeit und Verfügbarkeit filtern Kandidaten vor der Gewichtsauswahl.
  • Fork Choice und Finalität sind dieselbe Regel. Ersterer wählt den zu erweiternden Head; Letztere schützt einen Vorfahren mit Zusatzbedingungen.
  • Jede Validatorstimme bleibt für immer in der Summe. Bei Latest Message ersetzt eine neuere zulässige Nachricht die frühere Fork-Unterstützung.
  • Ein Explorer beweist die kanonische Chain. Er meldet die Sicht eines Infrastrukturstacks; unabhängige Validierung und Abgleich bleiben nötig.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...