Was passiert bei einem Hard Fork?

Aktuell wird heiß diskutiert, ob die Maximalgröße von gefundenen Blöcken von aktuell 1 Mbyte auf beispielsweise 20 MByte angehoben werden soll. Wenn das passieren soll, muss es dafür einen Hard Fork geben. Dieser kluge Gastbeitrag von Dr. Carsten Otto beleuchtet, was ein Hard Fork ist und welche Szenarien denkbar sind.

Exkurs: Wie wird die Blockchain aufgebaut?

Für die weiteren Erläuterungen in diesem Artikel sollte man ein Grundverständnis haben, was die Blockchain ist und wie diese aufgebaut ist. Dieser kleine Exkurs ist stark vereinfachend, reicht aber aus, um die Problematik eines Hard Forks zu verstehen.

Die Blockchain ist der Kern von Bitcoin. Die einzelnen Benutzer, dazu zählen auch Börsen wie bitcoin.de, überprüfen mit den Daten der Blockchain, ob eine Transaktion gültig ist. Die Blockchain enthält hierfür alle Transaktionen seit es Bitcoin gibt, und deshalb kann man überprüfen, ob eine Transaktion gültig ist oder aus dem Nichts kommt, oder ob ein Betrag mehrfach ausgegeben wurde (was natürlich nicht erlaubt ist). Um die Organisation zu vereinfachen, werden Transaktionen in Blöcke zusammengefasst, wobei jeder Block aktuell höchstens 1 MByte groß sein darf.

Die Blockchain kann nicht nachträglich verändert werden und es ist auch recht schwer, neue Blöcke in die Blockchain hinzuzufügen. Ist aber erst einmal etwas in der Blockchain gespeichert, darf man dies nach einer kurzen Wartezeit getrost als Wahrheit betrachten und darauf vertrauen.

Die Blockchain ist, wie der Name schon andeutet, eine Kette von Blöcken. Im Schnitt wird alle 10 Minuten ein Block an diese Kette angehängt, so dass heute rund 360.000 Blöcken existieren. Gelegentlich passiert es, dass zwei neue Blöcke (A und B) nahezu zeitgleich gefunden werden. In diesem Fall gibt es weltweit zwei verschiedene Blockchains, wobei eine in Block A endet, die andere in Block B. Jeder einzelne Rechner entscheidet sich für die Blockchain mit dem zuerst gesehenen neuen Block, und ignoriert die Blockchain, die im anderen neuen Block endet.

Diese Unstimmigkeit wird aber schnell wieder gelöst, da jeder neue Block immer nur an die jeweils längste gültige Kette angehängt wird. Wenn also ein Miner einen weiteren neuen Block findet, der auf Block A basiert, ist diese Blockchain länger und das komplette Netzwerk ist sich wieder einig, welche Blockchain betrachtet wird.

Was ist ein Hard Fork?

Ein Hard Fork ist das Ergebnis einer Änderung im Bitcoin-Protokoll, die nicht abwärts-kompatibel ist. Ältere Clients verstehen diese Änderung nicht und verwerfen im Zweifel einzelne Transaktionen oder Blöcke als ungültig, ignorieren diese also. Im Kontext von größeren Blöcken ist das leicht zu verstehen: ein Block, der größer als 1 MByte ist, wird von den aktuellen Clienten als zu groß angesehen und verworfen. Befürworter größerer Blöcke können also nicht einfach so größere Blöcke in die Welt schicken, man muss auch dafür sorgen, dass diese akzeptiert werden. Dies ist nur möglich, indem man entsprechend angepasste Sofware bei den einzelnen Anwendern laufen lässt.

Eine solche Anpassung ist technisch vergleichsweise einfach: muss man im Beispiel von oben im Quellcode eigentlich nur eine Zahl von “1 MByte” auf “20 MByte” ändern. Sehr viel schwieriger ist es, diese neue Software auch bei den Benutzern laufen zu lassen. Die dafür nötige Überzeugungsarbeit, die schließlich zu einem Konsens führen muss, ist die eigentliche Herausforderung. Bei einem Hard Fork wird ein Block (nennen wir ihn X) gefunden, der von der älteren Version verworfen, von der neueren Version aber akzeptiert wird. Ab diesem Block X entwickeln sich parallel zwei Blockchains.

Eine der Blockchains wird von den Benutzern der älteren Version, wie gewohnt, mit zusätzlichen Blöcken versorgt. Hierbei wird Block X ignoriert. Eine zweite Blockchain wird nur von den neueren Clients ausgebaut, wobei diese Blockchain sich ab Block X von der anderen Blockchain unterscheidet. Unabhängig davon wie lang die einzelnen Ketten werden, ältere Clients werden die Kette mit Block X ignorieren, da immer nur die längste gültige Kette betrachtet wird. Neuere Clients können, je nachdem wie groß die beiden Ketten werden, hin und her wechseln, oder sich dauerhaft für eine Kette entscheiden – möglicherweise anders als die älteren Clients.

Konsequenzen

Welche Szenarien sind nun denkbar, wenn eine neue Software-Version veröffentlicht wird, die größere Blöcke findet und akzeptiert?

Szenario 1 (fehlende Miner-Unterstützung)

Ein sehr einfacher Fall wäre, dass die angepasste Software zwar bei beliebig vielen Endnutzern, Börsen-Betreibern und Händlern verwendet wird, aber die Miner trotzdem keinen Block größer als 1 MByte veröffentlichen. Nur die Miner entscheiden, welche Transaktionen bestätigt werden, und auch wie groß die gefundenen Blöcke sind. In diesem recht theoretischen Szenario ändert sich verglichen zum aktuellen Stand nichts.

Szenario 2 (fehlende Benutzer-Unterstützung)

Rein theoretisch denkbar ist auch, dass zwar alle Miner die neue Version benutzen und auch große Blöcke finden, allerdings sämtliche Benutzer, Händler und Börsenbetreiber noch die alte Version benutzen und demzufolge die (zu) großen Blöcke ignorieren. Für den Benutzer sieht dieses Szenario so aus, dass keine neuen Blöcke mehr gefunden werden, also Transaktionen nicht mehr bestätigt werden.

Für die Miner ist dieses Modell aber auch ungünstig. Pro gefundenem Block bekommt ein Miner (aktuell) 25 BTC Belohnung. Da der jeweilige Block aber von sämtlichen Börsen und Händlern nicht als gültig angesehen wird, kann diese Belohnung nicht sinnvoll ausgegeben werden. Die Miner sind dementsprechend daran interessiert, dieses Szenario zu vermeiden, und würden sich mit den Benutzern abstimmen.

Szenario 3 (große Minderheit)

Im einfachsten Fall wird die neue Version nur von wenigen Benutzern und Minern verwendet. Neu gefundene Blöcke, die größer als 1 MByte sind, werden zwar von diesem “elitären” Kreis als gültig anerkannt, aber vom restlichen Netzwerk ignoriert. Auf blockchain.info wird man von diesen großen Blöcken nie etwas sehen, und die 25 BTC Belohnung für einen in der alternativen Blockchain gefundenen Block kann man auch, ähnlich wie im vorherigen Szenario, bei keinem Händler außerhalb des kleinen Kreises eintauschen.

Szenario 4 (keine Mehrheit)

Das denkbar ungünstigste Szenario entsteht, wenn beide Software-Versionen aktiv verwendet werden. In diesem Szenario entwickeln sich parallel zwei Blockchains. Da die Miner komplett frei entscheiden können, welche gültigen Transaktionen in neue Blöcke verpackt werden, gibt es in den beiden Blockchains recht schnell unterschiedliche Informationen. In einer Blockchain kann das Geld für ein gekauftes Auto bereits beim Verkäufer sein, in der anderen Blockchain steckt es noch in der Wallet des Käufers. Durch geschickte, aber nicht besonders schwierige Manipulationen kann man so ein Szenario nach einem Hard Fork auch erzwingen.

Als Konsequenz entstehen nicht nur zwei Blockchains, sondern auch potentiell unterschiedliche Bestände in den einzelnen Wallets. Dadurch entwickeln sich effektiv zwei Währungen mit jeweils einem eigenen Kurs – wenn man Bitcoin denn als Währung bezeichnen möchte. Man muss dann bei jeder Transaktion beachten, dass alle relevanten Teilnehmer sich auf die gleiche Blockchain beziehen. Die Wallet-Adressen sind in beiden Varianten gleich, aber die Bestände und bestätigten Transaktionen nicht.

Gegner der größeren Blöcke haben bereits angekündigt, ihre Bestände nach einem Hard Fork in der Blockchain der großen Blöcke zu verkaufen, und sie in der anderen Blockchain zu behalten. Solche Verkäufe drücken natürlich den Kurs. Ökonomisch ist es aber auch für Befürwörter von größeren Blöcken sinnvoll, sich auch so zu verhalten – also die Bestände in der Blockchain der kleinen Blöcke zu verkaufen. Konsequent weitergedacht ist es durchaus denkbar, dass nach einem Hard Fork beide Bitcoinvarianten (höchstens) halb so viel wert sind wie vor dem Hard Fork.

Insgesamt ist dieses Szenario unbedingt zu vermeiden, da sehr viel Chaos entsteht und beide Blockchain-Varianten im Vergleich zum aktuellen Stand geschwächt werden.

Szenario 5 (große Mehrheit)

Analog zum dritten Szenario ist es auch gut möglich, dass eine große Mehrheit die neue Version einsetzt. Die Blockchain, die auf dem ersten (zu) großen Block basiert, wird von den Benutzern der alten Version ignoriert. Das fällt aber nicht ins Gewicht, da sämtliche relevanten Händler und Börsen ebenfalls die neue Version benutzen und Transaktionen wie schon vor dem Hard Fork als bestätigt ansehen. Der einfache Benutzer bemerkt den Hard Fork deshalb nicht.

Konsens

Es ist wichtig, einen Konsens zu erzeugen, so dass Szenario 4 vermieden wird. Die Frage ist, wie man zu einem Konsens kommt. Aktuell denkt Gavin Andresen darüber nach, eine neue Protokollversion, die größere Blöcke erlaubt, im Rahmen von Bitcoin XT zu veröffentlichen. Wer diesen Vorschlag unterstützen möchte, kann seine Miner und Clients also einfach auf diese Version umstellen. Wer eine Börse oder einen anderen namhaften Service betreibt, kann die eigene Software entsprechend anpassen und diese Entscheidung öffentlich machen – ein kurzer Tweet oder eine Pressemitteilung dürften ihren Zweck erfüllen.

Selbst wenn sich langfristig die Mehrheit für diese neue Version entscheidet, muss der Zeitpunkt für den Hard Fork sorgfältig gewählt werden. Wenn es sofort einen Hard Fork gibt, sind die Benutzer unsicher, ob diese Variante schnell von der Mehrheit unterstützt wird. Deshalb ist eine Möglichkeit, dass man einen festen Termin als Teil der Protokolländerung vorsieht, beispielsweise als Regel “diese Software akzeptiert ab dem 11.12.2015 große Blöcke”. Wenn kein Konsens zu erwarten ist, kann man dann immer noch kurz vorher die Änderungen durch eine Neuinstallation der (alten) Software rückgängig machen und es ist nichts passiert.

Möglich ist auch, dass man die Protokolländerung an eine in der Blockchain selber kommunizierte Bereitschaftsbekundung koppelt. Hierfür schreiben die Miner, die die neue Version laufen lassen, mit jedem gefundenen Block eine entsprechende Zusatzinformation in den Block. Vorgeschlagen wurde bereits das Kriterium “wenn von den letzten 12.000 Blöcken mindestens 75% der Änderung zustimmen, wird diese scharfgeschaltet”.

Fazit

Egal, ob Blöcke laut Vorschlag 20 MByte groß sein dürfen, oder doch nur 2 MByte, oder ob die maximale Blockgröße bei Bedarf vergrößert wird – ohne eine klare Mehrheit ist eine Protokollumstellung mit dem darauf folgenden Hard Fork schädlich für alles, was den Namen Bitcoin trägt. Im Zweifel ist der Status Quo – der nur Blöcke mit maximal 1 MByte erlaubt – die von der Mehrheit unterstützte Variante.

Über den Autor:

Dr. Carsten Otto ist Informatiker, wurde im Gebiet der Software-Verifikation promoviert und ist aktuell Software-Engineer bei andrena objects ag in Frankfurt, begeistert an der Technik hinter Bitcoin und Stammbesucher der Frankfurter Bitcoin-Community. Wer ihm für diesen Artikel etwas spenden will, kann dies bei dieser Adresse tun: 1BEgx5EF33CCDsaN1as8WZaemMhTF4uX6W