Wenn es um neue Funktionen und Updates für das Bitcoin-Netzwerk geht, spricht man häufig von sogenannten Soft- oder Hard Forks. Was sich hinter diesen Begriffen überhaupt verbirgt und wo die konkreten Unterschiede liegen, nehmen wir in diesem Beitrag genauer unter die Lupe. Auch räumen wir mit verbreiteten Missverständnissen auf, die häufig dazu führen, dass die beiden Begriffe falsch verstanden werden.
Ganz allgemein spricht man bei Software-Projekten, hauptsächlich im Bereich der Open-Source Entwicklung, von einer „Fork“, wenn sich diese in irgendeiner Form aufspalten, beispielsweise weil ein Teil der Entwickler andere Ideen und Vorstellungen von der Zukunft eines Projektes haben. Vor allem bei anhaltenden Diskussionen und Meinungsverschiedenheiten ist die Möglichkeit, jederzeit getrennte Wege gehen zu können, wichtig, anstatt sich zu sehr in Debatten und Streitereien festzufahren.
Der Begriff „Fork“ ist im Bitcoin Kontext leider mehrfach belegt und oft ist nicht klar, was überhaupt gemeint ist. Auch darauf werden wir im Laufe dieses Beitrages noch intensiver eingehen. Wichtig für den Moment ist jedenfalls, dass eine Fork wie im vorherigen Abschnitt für Bitcoin etwas Besonderes ist.
Anders als bei einer simplen Anwendung, die man theoretisch mit einem Klick „forken“ und beliebig anpassen kann, ist dies bei Bitcoin, einem großen und dezentralen Netzwerk, nicht so einfach möglich. Denn Regeländerungen, die Einfluss auf die Gültigkeit von Bitcoin Blöcken haben, sind für das gesamte Netzwerk und seine Nutzer relevant und können weitreichende Folgen haben.
Die Menge aller Regeln, die sich aktuell im Bitcoin-Netzwerk wiederfinden, gibt ganz genau vor, welche Blöcke gültig sind, und welche nicht. Alle sogenannte Konsensregeln, also die Regeln, die über die Gültigkeit eines Blockes entscheiden, sind das Herzstück von Bitcoin und machen das Netzwerk erst, zu dem, was es ist.
Will man an diesen Konsensregeln etwas verändern, kann man in genau zwei verschiedene Richtungen gehen: Man kann Regeln verschärfen, oder lockern. Und genau hier liegt die Unterscheidung zwischen einer Soft- und Hard Fork. Die beiden Begriffe beschreiben lediglich die Form der Regeländerung, nicht mehr und nicht weniger. Potenziell daraus resultierende Folgen für das Netzwerk, auf die wir später auch noch eingehen werden, sind zunächst nicht Teil dieser Unterscheidung und komplett getrennt zu betrachten.
Zur Veranschaulichung stellen wir uns ein vegetarisches Restaurant vor.
Auf der Speisekarte stehen also nur Gerichte, die kein Fleisch enthalten und von Vegetariern gegessen werden können. Eine Änderung der Speisekarte weg von dieser Eigenschaft kann jetzt potenziell Konflikte mit der aktuellen Kundschaft verursachen – oder auch nicht. Genau hier werden wir gleich die Feinheiten zwischen Soft- und Hard Fork näher kennenlernen.
Bei einer Soft Fork schränken wir die bestehenden Regeln ein. Im Fall unseres Restaurants verändern wir die Speisekarte so, dass gar keine Tierprodukte mehr in den Gerichten enthalten sind und somit auch Veganer im Restaurant essen können.
Man spricht hier von einer sanften Regeländerung, da die bisherigen Kunden, also die Vegetarier, nichts an ihrer Einstellung ändern müssen, um weiterhin das Restaurant besuchen zu können – denn ein Vegetarier kann sich schließlich auch ohne Probleme komplett vegan ernähren.
Im Bitcoin Kontext muss man bei einer Soft Fork also nicht gezwungenermaßen auf die neuen Regeln updaten, da sie nicht in direktem Konflikt mit den bisherigen Regeln stehen.
Zusammengefasst in wenigen Stichpunkten:
Kehren wir zu unserem mittlerweile veganen Restaurant zurück und ändern wieder etwas an den Regeln: Dieses Mal greifen wir wortwörtlich etwas härter durch und entfernen die Einschränkung der veganen Gerichte komplett. Es gibt von nun an ausschließlich Fleischgerichte, was allerdings zu einem harten Konflikt mit den bisherigen Kunden führt: Entweder sie akzeptieren die neuen Regeln und essen die Fleischgerichte, oder können das Restaurant zukünftig nicht mehr besuchen.
Zurück im Bitcoin Kontext ist das Besondere an einer Hard Fork also die Notwendigkeit, die neue, harte Regeländerung zu akzeptieren, da sie den alten Regeln widersprechen würde.
Zusammengefasst in wenigen Stichpunkten:
Über eine ganz besondere Fork haben wir bisher nicht gesprochen: Eine Aufteilung der Blockchain selbst, also miteinander konkurrierende Blöcke, die nicht mehr Teil der gleichen Blockchain sind. Eine solche „Fork“ bezeichnen wir im folgenden als Chain Split, um Verwechslungen mit der bisherigen Bedeutung des Begriffes zu vermeiden.
Denn sehr häufig werden Chain Splits mit Forks, vor allem Hard Forks gleichgesetzt und synonym verwendet. Wie immer bei verbreiteten Missverständnissen steckt auch ein bisschen Wahrheit dahinter. Trotzdem ist es sehr wichtig, den Unterschied zwischen einem Chain Split und einer Soft- oder Hard Fork richtig verstanden zu haben.
Ein Chain Split ist ein klar definierter Zustand im Netzwerk, nämlich wenn gleichzeitig mehrere Blöcke an der Spitze („Chaintip“) der Blockchain stehen und miteinander konkurrieren. Tatsächlich können solche Chain Splits zufällig und damit auf natürliche Weise auftreten, ganz ohne Soft- oder Hard Fork, beispielsweise wenn zwei unabhängige Miner zufällig zur gleichen Zeit einen neuen Block finden.
Lese-Tipp: Ungewöhnliche Bitcoin Blöcke und wo sie zu finden sind
Die Begriffe der Soft- und Hard Fork hingegen sind lediglich Kategorisierungen für die Art oder „Richtung“ einer Regeländerung. Das eine kann mit dem anderen etwas zu tun haben – muss es aber nicht. Anders als häufig angenommen, muss eine Hard Fork nämlich nicht zwingend in einem Chain Split enden und umgekehrt kann eine Soft Fork trotz „sanfter“ Regeländerung sehr wohl zu einer solchen Spaltung der Blockchain führen. Warum das so ist, schauen wir uns an einem beliebten Beispiel, nämlich der maximalen Blockgröße an.
Das hart in den Bitcoin-Regeln festgelegte Limit der Blockgröße können wir vereinfacht in genau zwei Richtungen verändern: Vergrößern oder Verkleinern.
Wir erinnern uns: Eine Verkleinerung der maximalen Blockgröße ist eine Einschränkung einer bestehenden Regel, und damit als Soft Fork zu kategorisieren. Die Vergrößerung hingegen wäre eine Lockerung der Regel und damit eine Hard Fork. Schauen wir uns also die jeweiligen Szenarien an, wann die beiden Arten der Regeländerungen zu einem Chain Split führen würden – und wann nicht.
Wir verringern die maximale Blockgröße von 1 MB auf 0,5 MB. Blöcke, die unter den alten Regeln entstehen, sind also potenziell ungültig.
Sichtweise der alten Version:
Wir erhöhen die maximale Blockgröße von 1 MB auf 10 MB. Blöcke, die unter den alten Regeln entstehen, sind also weiterhin uneingeschränkt gültig.
Sichtweise der alten Version:
Sichtweise der neuen Version:
Durch die Vorwärts-Kompatibilität einer Soft Fork sind die neuen Blöcke für alte, nicht aktualisierte, Versionen trotzdem gültig. Es müssen also nicht alle Teilnehmer des Bitcoin-Netzwerks auf die neue Version aktualisieren, um eine erfolgreiche Aktivierung der Änderung zu erreichen.
Daher kommt es bei einem sorgfältig geplanten Update auch nicht zu einem Chain Split. Möglich ist das allerdings trotzdem, beispielsweise wenn viele Miner noch auf der alten Version weiter arbeiten und Blöcke produzieren, die hier im Beispiel eine zu große Blockgröße haben.
Sichtweise der neuen Version:
Da bei einer Hard Fork keine Vorwärts-Kompatibilität vorliegt, sind die neuen Blöcke für alte Versionen ungültig. Es müssen also alle Teilnehmer des Bitcoin-Netzwerks gemeinsam auf die neue Version aktualisieren, um einen Chain Split, also einen Konflikt direkt auf der Blockchain, zu verhindern.
Genau das ist aber vor allem bei kontroversen Entscheidungen nicht realistisch, weshalb Hard Forks häufig in zwei verschiedenen Netzwerken enden, wie zum Beispiel bei der Abspaltung von Bitcoin Cash im Jahr 2017.
Wer sich mit dem Segregated Witness (SegWit) Update aus 2017 auskennt, wird sich wahrscheinlich fragen: Wie kann es sein, dass damals die maximale Blockgröße erhöht wurde, obwohl es sich bei SegWit ganz klar um eine Soft Fork handelte?
Die Antwort auf diese berechtigte Frage ist mehr oder weniger recht einfach: Die eigentliche Beschränkung der Blockgröße wurde nämlich gar nicht verändert, diese liegt also nach wie vor bei 1 MB, sondern nur indirekt über einen zusätzlichen Datenanhang, der getrennt vom eigentlichen Block übertragen wird. Aus Sicht einer alten Version von Bitcoin, die nichts von SegWit wissen will, existiert dieser Anhänger also gar nicht und die zusätzlichen Daten stellen keinen Konflikt dar. Die Transaktionen in den Blöcken sind dabei so konstruiert, dass sie auch ohne die zusätzlichen SegWit-Daten als gültig ausgewertet werden können.
Wir halten fest: Auch komplexe Änderungen, die auf den ersten Blick eine Hard Fork fordern, können durch elegante Design-Entscheidungen auch mit einer Soft Fork realisiert werden.
Du findest es spannend dir über Neuerungen von Bitcoin und wie diese umgesetzt werden können Gedanken zu machen? Dann ist The Blocksize War genau der richtige Lesestoff für dich!