Zum Inhalt springen
Financial Context Wiki

Hard Fork und Soft Fork: Regelkompatibilität, Aktivierung und Chain-Splits

Hard Fork und Soft Fork bezeichnen unterschiedliche Kompatibilitätsbeziehungen zwischen alten und neuen Konsensregeln. Gültige Blockmengen, Aktivierung, Node-Prüfung, Produzenten, Betriebsbereitschaft, Replay-Risiko und eine mögliche Kettenteilung sind getrennt zu analysieren.

Aktualisiert

Nur zur Protokollanalyse und zu Bildungszwecken; keine Anlageberatung. Ein vorgeschlagener oder aktivierter Fork kann Validierung, Ein- und Auszahlungen, Verwahrung, Verträge, Preise, Liquidität, Steuern und Betriebssicherheit beeinträchtigen und garantiert keinen zweiten dauerhaften Vermögenswert.

Direkte Antwort

Hard Fork und Soft Fork klassifizieren eine Konsensregeländerung danach, wie aktualisierte und nicht aktualisierte Nodes Blöcke bewerten. V_old sei die unter alten Regeln akzeptierte Blockmenge, V_new die neue. Ein Soft Fork beschränkt die Gültigkeit auf V_new subset V_old: Jeder neu gültige Block ist auch alt gültig, doch alte Nodes erzwingen die Zusatzregel nicht. Ein Hard Fork erlaubt mindestens einen neu gültigen Block, den alte Nodes ablehnen: exists b: b in V_new and b not in V_old. Die Mengen können erweitert oder unvergleichbar sein; „hard“ bedeutet nicht bloß größerer Block oder radikalere Funktion.

Kompatibilität ist asymmetrisch. Bei erfolgreichem Soft Fork bleiben alte Nodes auf derselben Kette, weil sie Blöcke aktualisierter Miner oder Validatoren akzeptieren. Sie können aber etwas akzeptieren, das neue Nodes ablehnen, und bieten schwächere Sicherheit. Beim Hard Fork können alte Nodes einem neu gültigen, alt ungültigen Block nicht folgen. Tragen wirtschaftlich relevante Teilnehmer beide Regeln weiter, können zwei dauerhafte Netze entstehen; ohne wirksame Unterstützung einer Seite müssen keine zwei Vermögenswerte bleiben.

Die Begriffe beschreiben Regeln, nicht Legitimität, Sicherheit, wirtschaftliche Unterstützung oder Aktivierung. Ein Vorschlag kann vor Aktivierung Hard Fork heißen, eine Aktivierung ohne dauerhaften Split enden und ein Implementierungsfehler ohne Abstimmung die Kette teilen. Signale koordinieren Bereitschaft, machen für einen Full Node jedoch keinen nach seinen Regeln ungültigen Block gültig.

Nicht zu verwechseln sind Konsens-Fork, vorübergehender Same-Rule-Fork, Reorganisation, Repository-Fork und App-Upgrade. Entscheidend ist, welches Netz, welche Regeln, Aktivierungsbedingung und Historie jeder Node, Wallet-Anbieter, Handelsplatz, Verwahrer, Oracle und Vertrag anerkennt.

Einen Protokoll-Fork analysieren

  1. Identität und Umfang fixieren. chain, network, client version, Vorschlag, Genesis- oder finalisierten Checkpoint, aktuellen Block-Hash und Ebene erfassen. Derselbe Name kann auf Testnet, Mainnet, Ausführungs-, Konsens- oder Anwendungsebene anderes bedeuten.
  2. Konsensgültigkeit vergleichen. Alle geänderten Block-, Transaktions-, Signatur-, Zustands-, Gas-, Zeit-, Finalitäts- und Fork-Choice-Regeln auflisten. Objekte in beiden Versionen als valid, invalid oder unknown einstufen; Release Notes allein genügen nicht.
  3. Mengenbeziehung beweisen. Prüfen, ob jedes neu gültige Objekt alt gültig bleibt. Dann ist Soft-Fork-Kompatibilität möglich. Ein neu gültiger, alt ungültiger Block verlangt für diese Nodes einen Hard-Fork-Übergang. Auch alt gültige, neu ungültige Objekte testen.
  4. Aktivierung reproduzieren. Höhe, Epoche, Medianzeit, Signalgrenze, Lock-in-Verzögerung, Gesamtschwierigkeit oder Governance-Auslöser in Spezifikation und Code prüfen. Signalisierung, Lock-in, Aktivierung und Durchsetzung sind verschieden.
  5. Teilnehmer abbilden. Aktualisiertes Produktionsgewicht sowie Full Nodes, Relays, Wallets, Börsen, Verwahrer, Bridges, Stablecoin-Emittenten, Oracles und Verträge je Seite erfassen. Hashrate oder Stake allein bestimmen keine wirtschaftliche Akzeptanz.
  6. Split und Transaktionen verfolgen. Parent-Hashes und Gültigkeit nach beiden Regeln prüfen. Bestätigungen, Mempool, Replay-Schutz, Adressen, Chain-IDs, Signaturdomänen, Auszahlungen und Ausführung auf beiden Zweigen kontrollieren.
  7. Betrieb absichern. Bei unklarer Abstammung Abwicklung pausieren oder verlängern; bewusst aktualisieren und sichern; Salden und Verpflichtungen je Zweig abstimmen; Signatur und Wiederherstellung offline testen; erst nach klaren Chain-, Node-, Gegenpartei- und Finalitätskriterien fortfahren.

So werden vier oft als „Fork“ zusammengefasste Ereignisse getrennt: Regelvorschlag, Aktivierungsbedingung, beobachtete Divergenz und späteres wirtschaftliches Fortbestehen eines oder mehrerer Zweige. Keines beweist automatisch das nächste.

Rechenbeispiele

1. Kompatibilität gültiger Mengen

Akzeptieren alte Regeln 100 Blockformen und neue nur 80, liegt bei vollständiger Einbettung dieser 80 ein Soft-Fork-Verhältnis vor; die übrigen 20 alten Formen lehnen neue Nodes ab. Die Zahlen zeigen Mengen, keine Wahrscheinlichkeiten oder Abstimmungsgrenzen.

Akzeptieren neue Regeln eine Blockform, die alle alten Nodes ablehnen, bricht schon dieses Gegenbeispiel die Abwärtsakzeptanz, auch wenn fast alles andere beidseitig gültig ist. Ob der Split bleibt, hängt danach von Produzenten, Nutzern und Infrastruktur ab.

2. BIP-34-Aktivierung ist nicht die Definition

BIP 34 verlangte die Blockhöhe in der Coinbase-Transaktion und nutzte rollierende Bereitschaft. Bei 750 of 1,000 vorherigen Blöcken ab Version 2 wurden ungültige Version-2-Blöcke abgelehnt; nach 950 of 1,000 auch Version 1. Block 227,835 war laut BIP der letzte Version-1-Block.

Die Schwellen koordinierten die Einführung, definierten aber nicht den Soft Fork. Kompatibilität entstand durch enger prüfende neue Nodes, während alte Clients konforme Blöcke akzeptierten. BIP 9 trennte später Bereitstellungszustände und Versionsbits und damit Regelbeziehung von Aktivierungsmechanik.

3. Segregated Witness als Soft Fork

BIP 141 führte witness-Daten ein und band deren Baum über die Coinbase-Transaktion in die bestehende Commitment-Struktur ein. Alte Nodes konnten konforme Blöcke ohne Prüfung der neuen Witness-Regeln akzeptieren, neue Nodes erzwangen sie.

Das ist Abwärtsakzeptanz, nicht gleiche Prüfung. Alte Nodes sehen neue Ausgaberegeln gegebenenfalls weniger streng; wer deren Sicherheit nutzt, braucht aktualisierte Validierung. „Alte Software läuft weiter“ ist keine vollständige Risikoanalyse.

4. Ethereums DAO Fork

EIP-779 dokumentiert den DAO Fork bei Mainnet-Block 1,920,000: Eine irreguläre Zustandsänderung übertrug Salden aus Kontenliste L an den Vertrag WithdrawDAO, ohne EVM-Opcodes, Transaktionsformat oder Blockstruktur zu ändern.

Anwendende und ablehnende Nodes berechneten danach verschiedene Zustände. Ein Hard Fork braucht also weder größere Blöcke noch neue Opcodes; eine einmalige Zustandsregel reicht, und fortgesetzte Unterstützung beider Historien kann getrennte Netze erhalten.

Risiken und Prüffehler

Klassifikations- und Spezifikationsfehler

  • Jede kurz konkurrierende Spitze Hard Fork nennen, obwohl gleiche Regeln und normale Fork Choice sie auflösen.
  • Jede Lockerung als Hard Fork und jede Verschärfung als Soft Fork definieren, ohne gültige Mengen zu testen.
  • Abwärtsakzeptanz mit voller Sicherheit gleichsetzen; alte Nodes erzwingen die Zusatzregeln nicht.
  • Konsens aus Marke, Roadmap, Release Note oder Repository statt aus eingesetztem Code und Parametern ableiten.
  • Mainnet, Testnet, Ausführung, Konsens, Bridge, Rollup und Anwendung vermischen.
  • Vorschlag, Client-Release, Signalisierung, Lock-in und Aktivierung für dasselbe Ereignis halten.
  • Produzentensignale als bindende Abstimmung von Nutzern, Börsen, Verwahrern oder Full Nodes behandeln.

Split- und Transaktionsrisiken

  • Annehmen, Aktivierung garantiere Split oder Split garantiere zwei liquide, dauerhafte Vermögenswerte.
  • Nur Höhe nutzen, obwohl Zweige dort verschiedene Blöcke haben können; Hashes und Abstammung prüfen.
  • Ohne Replay-Schutz, Chain-IDs, Signaturdomänen und zweigspezifische Konstruktion senden.
  • Einzahlung auf einem Zweig gutschreiben, Verbindlichkeit oder Auszahlung auf dem anderen begleichen.
  • Nur einem Explorer, RPC oder Verwahrerlabel vertrauen, obwohl Anbieter andere Regeln oder Verzögerung haben können.
  • Reorganisation, stockende Finalität, Partition, Minderheits-Mining, Doppelvotum oder fehlende Daten ignorieren.
  • Gleiche Emittentendeckung für Symbol, Vertrag, Stablecoin, Oracle-Preis oder Bridge-Anspruch beider Zweige annehmen.

Governance- und Betriebsrisiken

  • Kompatibilität als Beleg für Legitimität, Dezentralität, Sicherheit oder wirtschaftliche Unterstützung darstellen.
  • Produktions-Nodes ohne reproduzierbare Binärdateien, Backups, Rollback-Grenzen, Migrationstest und Hash-Prüfung aktualisieren.
  • Downgrade nach neuen Zustandsdaten, Wallet-Formaten oder Slashing-Bedingungen stets für sicher halten.
  • Schlüssel mit ungeprüfter Software bewegen oder „Fork-Coins beanspruchen“ und Geheimnisse oder Signaturen gefährden.
  • Snapshot-Salden ohne Reife, Sperren, Vertragszustand und Verwahrungsregeln sofort verfügbar nennen.
  • Steuer-, Bilanz- oder Werturteile vor Klärung von Eigentum, Kontrolle, Liquidität und lokalem Recht treffen.

Häufige Irrtümer

  • Ein Hard Fork erzeugt immer einen neuen Coin. Ein zweiter Wert braucht Produktion, Nutzer, Infrastruktur und Markt; viele Upgrades enden bei einer Historie.
  • Ein Soft Fork ist risikolos, weil alte Nodes laufen. Sie folgen möglicherweise, erzwingen aber die neue Regel nicht und prüfen schwächer.
  • Mehrheitliche Hashrate oder Stake kann allein jede Regel ändern. Full Nodes lehnen nach eigenen Regeln ungültige Blöcke ab; Gewicht wirkt nur unter akzeptierten Blöcken.
  • Hard heißt umstritten, soft heißt einhellig. Die Begriffe klassifizieren Kompatibilität, nicht sozialen Konsens oder Governance.
  • Jeder Explorer-Fork ist ein Upgrade. Same-Rule-Blöcke und Reorganisationen entstehen ohne Konsensregeländerung.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...