Newsticker

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.
cotto1
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.

cotto2

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

Über Christoph Bergmann (2638 Artikel)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder ---

4 Kommentare zu Was passiert bei einem Hard Fork?

  1. grüner Flamingo // 15. Juni 2015 um 14:17 // Antworten

    Ganz einfach:
    Wenn es keine totale Mehrheit für eine der beiden Lösungen gibt, ist die Blockchain der kleineren Blöcke theoretisch leicht im Vorteil, weil sie automatisch länger ist und damit eigentlich die einzige gültige Blockkette ist.

    Ich gehe davon aus, dass größere Blöcke länger zur Verarbeitung brauchen, also die Blockchain der klassischen (kleinen) Blöcke sich schneller verlängert. Gültig ist stets die längste Blockchain. Die Blockgröße ist bei beiden Blockchains <20MB, also sind dann beide für den neuen Client gültig!?

    Also keine gleichberechtigten Blockchains, sondern die alte Blockchain mit den kleinere Blöcken hat einen strategischen Vorteil.

    Die entscheidende Frage ist also, wie will man technisch umgehen, dass der neue Client nicht die falsche Blockchain erwischt. Davon allein hängt es meiner Mng. nach ab, welche Blockchain sich durchsetzen wird.

    • Carsten Otto // 15. Juni 2015 um 14:36 // Antworten

      Sorry, ich habe nicht gründlich genug gelesen. Ohne Mehrheit sieht es natürlich nicht so rosig aus, wie in meiner ersten Antwort geschrieben. Aber in dem Fall gibt es ja auch ganz andere Probleme.

      Die Verarbeitungszeit ist meiner Ansicht nach auch vernachlässigbar, da die Blöcke ja nicht zwingend sofort randvoll sind. Ein Block von 1,1 MByte wird auch schon als “zu groß” verworfen, verlängert aber die “neue” Blockchain.

      Es gibt Bestrebungen, nach einem Hardfork eine weitere Version zu verteilen (dann allerdings ohne Hard Fork), die Block X aus dem Beispiel als zwingend nötigen Teil der Blockchain definieren. Da die längste Blockchain der kleinen Blöcke niemals durch X verläuft, kann man dadurch ein Zurückwechseln vermeiden.

  2. Carsten Otto // 15. Juni 2015 um 14:33 // Antworten

    Die Blockchain der kleineren Blöcke wäre leicht im Nachteil, da ab der Existenz von X die Blockchain der größeren Blöcke einen Block Vorsprung hat. Clients, die auch größere Blöcke akzeptieren, betrachten beide Blockchains als gültig und würden (wenn man weitere Tricks mal außen vor lässt) gegebenenfalls wieder auf die Blockchain der kleinen Blöcke wechseln. Dafür ist es aber nötig, dass dort der Rückstand aufgeholt wird, während die Unterstützer von größeren Blöcken weiterhin “ihre” Blockchain verlängern (und, da sie in der Mehrheit sind, damit vermutlich auch Erfolg haben).

    Wenn der zweite Block hinter X angehängt wird, bevor sich die Blockchain der kleineren Blöcke verlängern kann, muss man nun schon einen Rückstand von zwei Blöcken aufholen.

    Und selbst wenn das alles gelingt, wiederholt sich das Szenario beim nächsten großen Block (X’).

  3. Guter Beitrag, dafür ein Lob.

    Theoretisch sind diverse Szenarien möglich, doch ich gehe davon aus, dass die HardFork ohne nennenswerte Nebeneffekte erfolgen wird, weil eine deutliche Mehrheit von 80%+ für eine Aufweitung der Blöcke stimmen.

    Es gibt meiner Meinung nach keine vernünftigen Argumente gegen eine Aufweitung der Blockgröße, es sei denn man strebt eine Nieschenwährung an.

    Auch das Argument, dass Mining durch steigende Transaktionsgebühren lukrativer werden würde bzw. größere Blockgrößen die Gebühren niedrig hält, beruht auf einem fehlenden Verständnis für den Mechanismus des Minings.
    Mining ist egal wie hoch die Gebühren und der Reward tendenziell immer ein Nullsummenspiel, bei dem die cleveren Miner gewinnen und die weniger cleveren Miner verlieren.
    Der Aufwand richtet sich letztendlich immer nach den erwarteten Einnahmen bestehend aus dem Reward sowie den Transaktionsgebühren.
    Sinken die Einnahmen, sinkt zwangsläufig auch der Aufwand um einen Block zu generieren.
    Steigen die Einnahmen, steigt auch der Aufwand.
    Sinkt der Tauschkurs, sinkt der Aufwand.
    Steigt der Tauschkurs, steigt der Aufwand.

    Insofern bleibt da lediglich das Argument, dass die Blockchain mit Microtransaktionen zugemüllt wird, z.B. für Werbe/SPAM-Zwecke.
    Sicherlich würden steigende Transaktionsgebühren den SPAM unterbinden, doch muss man dafür die Blockgröße limitieren? Da gäbe es sicherlich andere elegantere Lösungen.

5 Trackbacks / Pingbacks

  1. Kernentwickler diskutieren konkrete Vorschläge zum Blocksize-Thema | BitcoinBlog.de - das Blog für Bitcoin und andere virtuelle Währungen
  2. Die wichtigsten Fragen und Antworten zur möglichen Fork durch XT | BitcoinBlog.de - das Blog für Bitcoin und andere virtuelle Währungen
  3. Konsens in Sicht? Beinah 60 Prozent der Miner für BIP100 | BitcoinBlog.de - das Blog für Bitcoin und andere virtuelle Währungen
  4. Warum XT und BIP101 so gefährlich sind | BitcoinBlog.de – das Blog für Bitcoin und andere virtuelle Währungen
  5. Hard Fork der Distributed Ledger - Bitcoins Today

Kommentar verfassen

%d Bloggern gefällt das: