Damit Bitcoin funktioniert, müssen sich alle Benutzer auf eine Historie von Transaktionen (die Blockchain) und auf eine Reihe grundlegender Regeln einigen, die definieren, was in dieser Blockchain akzeptiert wird und was in dieser Blockchain nicht akzeptiert wird. Wenn dieser Konsens nicht erreicht werden kann, kann die Nutzergemeinschaft in zwei verschiedene Netzwerke aufgeteilt werden, von denen jedes seine eigenen Regeln hat. Genau das geschah 2017 während des Hard Forks, aus dem Bitcoin Cash (BCH) hervorging.
Aber wie sind wir dorthin gekommen? In diesem Artikel lade ich Sie ein, diese als „Blocksize War“ bekannte Zeit der Konflikte innerhalb der Bitcoin-Community noch einmal zu erleben, um zu verstehen, wie diese Debatte die Ideologie der Bitcoiner nachhaltig geprägt hat.
Der Ursprung des Konflikts
Der Blocksize-Krieg entstand in einer technischen Debatte über die Fähigkeit von Bitcoin, ein steigendes Transaktionsvolumen abzuwickeln. Dies wird manchmal als „Skalierbarkeit“ oder „Hochskalierung“ bezeichnet. Da Satoshis Erfindung als Zahlungsmethode eingesetzt wird, muss sie in der Lage sein, die Transaktionen neuer Nutzer abzuwickeln und gleichzeitig angemessene Gebühren zu zahlen.
Zu diesen technischen Einschränkungen, die den Transaktionsfluss reduzieren, gehört offensichtlich die Blockgrößenbeschränkung der Blockchain. Je größer die Blöcke sind, desto mehr Transaktionen können aufgenommen werden, die bestätigt werden müssen.
Bei seiner Einführung im Jahr 2009 gab es für Bitcoin keine ausdrückliche Begrenzung dieser Größe. Im Jahr 2010 führte Satoshi Nakamoto jedoch ein Limit von 1 Megabyte ein (über die Konstante MAX_BLOCK_SIZE). Der Zweck dieser Änderung bestand darin, Transaktions-Spam-Angriffe zu verhindern und eine gewisse Dezentralisierung des Netzwerks sicherzustellen, indem verhindert wurde, dass zu große Blöcke die Ressourcen der Knotenbetreiber monopolisieren.
Zu diesem Zeitpunkt war die Größe von 1 MB mehr als ausreichend, um die geringe Anzahl von Transaktionen im Netzwerk zu unterstützen. Als Bitcoin jedoch immer beliebter wurde, begann die Community darüber zu diskutieren, ob dieses Limit erhöht werden muss, um das Transaktionsvolumen besser verwalten zu können, ohne dass die Gebühren in die Höhe schnellen. Auf diese Weise entstand eine erste Kluft innerhalb der Bitcoin-Community. Einige, die später als „Big Blocker“ bezeichnet wurden, glaubten, dass eine Erhöhung der Blockgröße eine einfache und unkomplizierte Lösung zur Lösung von Überlastungsproblemen sei. Im Gegensatz dazu argumentierten andere, die als „kleine Blocker“ bezeichnet werden, dass bei diesem Ansatz die Gefahr einer Zentralisierung des Netzwerks durch Erhöhung der Hardwareanforderungen der Knoten bestünde.
Da jeder komplette Knoten die gesamte Blockchain überprüfen und dann im Speicher speichern muss, benötigen größere Blöcke Festplatten mit größerer Kapazität, was teurer ist und die Anreize, einen eigenen Knoten zu betreiben, verringert. Wenn es weniger Bitcoin-Knoten gibt, ist die Systemsicherheit weniger gut verteilt, was das individuelle Zwangsrisiko erhöht, da die Sicherheit auf eine geringere Anzahl von Akteuren konzentriert wird.
Diese Diskussionen über Blockgrößen sind noch älter als der Zeitraum 2015-2017. In Wirklichkeit wurden bereits 2010 Vorschläge zur Erhöhung des Grenzwerts unterbreitet, wie zum Beispiel Der von Jeff Garzik vorgeschlagene Patch.
Aber erst ab 2015 wurde die Debatte zu einem Konflikt, mit einer ersten Offensive seitens der Entwickler von Bitcoin XT, einem alternativen Client, der von Mike Hearn ins Leben gerufen und von Gavin Andresen unterstützt wurde (ehemaliger Hauptbetreuer von Bitcoin nach dem Abgang von Satoshi Nakamoto). Bitcoin XT war ursprünglich eine Implementierung des Bitcoin-Protokolls, das mit Bitcoin Core kompatibel ist. Im August 2015 wurde in Version 0.11A von Bitcoin XT jedoch BIP101 eingeführt: ein Hard Fork, der das Blockgrößenlimit sofort von 1 MB auf 8 MB erhöht. Zusätzlich wurde ein Mechanismus hinzugefügt, um dieses Limit alle zwei Jahre zu verdoppeln, bis 2036 etwas mehr als 8 GB pro Block erreicht wurden. Tatsächlich haben sich die Bitcoin XT-Knoten daher vom Rest des Bitcoin-Netzwerks getrennt. Diese Meisterleistung wird von vielen als der Casus Belli der Blockkriegsführung angesehen.
Kleine Blocker versus große Blocker
Der Blocksize-War-Konflikt war in zwei gegensätzliche Lager gegliedert: die „großen Blocker“ und die „kleinen Blocker“, die jeweils einen anderen Ansatz zur Lösung des Bitcoin-Skalierbarkeitsproblems verteidigten.
Die „großen Blocker“ befürworteten eine Erhöhung der Blockgrößen, damit Bitcoin eine größere Anzahl von Transaktionen verarbeiten kann. Für sie war ein solcher Ansatz erforderlich, um die Transaktionsgebühren zu senken und das Nutzererlebnis zu verbessern, da Bitcoin immer beliebter wurde. Sie behaupteten auch, dass diese Lösung technisch einfach über Hardforks zu implementieren sei. Insbesondere die „Big Blocker“ wurden von frühen Entwicklern wie Gavin Andresen, Jeff Garzik, Mike Hearn und einflussreichen Akteuren wie Roger Ver und der Mehrheit der Bergbauunternehmen unterstützt. Für sie war der Anstieg der Blockgröße gleichbedeutend mit einem Anstieg ihrer Einnahmen. Wenn Sie in jedem Block mehr Transaktionen tätigen können, können Sie in der Tat auch mehr Gebühren erheben.
Im Gegensatz dazu waren die „kleinen Blocker“, die hauptsächlich von Bitcoin-Core-Entwicklern wie Pieter Wuille, Wladimir van der Laan, Peter Todd, Gregory Maxwell oder Luke Dashjr vertreten wurden, in ihrem Ansatz konservativer. Sie argumentierten, dass eine Erhöhung der Blockgröße das Risiko einer Netzwerkzentralisierung bergen würde, da dadurch die Knoten stärker belastet würden, was die Risikoverteilung einschränken würde. Die „kleinen Blocker“ wollten auch, dass Bitcoin skalierbar wäre, aber sie bevorzugten Skalierbarkeitslösungen, die Transaktionen von der Hauptblockkette wegverlagerten, wie zum Beispiel das Lightning Network. Die Idee war, ein großes Transaktionsvolumen zu verwalten, ohne das Basisprotokoll zu ändern, um die Dezentralisierung des Netzwerks und damit die Verteilung seiner Sicherheit zu gewährleisten. Kleine Blocker bevorzugen außerdem konservative Änderungen, die über Soft-Forks vorgenommen werden, anstatt über Hard-Forks.
Die technische Debatte zwischen diesen beiden Visionen der Skalierbarkeit hat die Bitcoin-Community tief gespalten. Jedes Lager mobilisierte Propaganda und Einflussstrategien, um zu versuchen, seine Ideen zu vermitteln.
Vorschläge und Versuche von Forks
Die Versuche und Vorschläge von Forks haben sich zwischen 2015 und 2017 vervielfacht. Wie wir gesehen haben, war der erste echte Fork-Versuch während des Blocksize-Krieges der von BIP101 auf Bitcoin XT. Dieser Vorschlag wurde von einer großen Anzahl von Minern und von Unternehmen unterstützt, die zu dieser Zeit einflussreich waren, wie BitPay, Blockchain.info oder Circle. Irgendwann wird Bitcoin XT nicht in der Lage sein, genügend Unterstützung von der Community zu erhalten, und Mike Hearn wird schließlich seine Abreise und den Verkauf seiner Bitcoins bekannt geben. Er wird seine Enttäuschung in einem Blogbeitrag zum Ausdruck bringen, in dem er insbesondere Folgendes feststellt:“ Bitcoin ist gescheitert “. Bitcoin XT markierte somit den Beginn tiefgreifender Unterschiede in der Community, und bald darauf folgten weitere Forks.
Anfang Dezember 2015 schlugen Pieter Wuille und Gregory Maxwell, Entwickler von Bitcoin Core, einen Soft-Fork namens „SegWit“ vor (Segregierter Zeuge). Dieser Vorschlag zielte darauf ab, Signaturdaten von Transaktionsdaten in der Blockchain zu trennen, um das Problem der Formbarkeit von Transaktionen zu lösen. Dieses Problem, das mit ECDSA, dem seit 2009 bei Bitcoin verwendeten Algorithmus für digitale Signaturen, zusammenhängt, ermöglicht es, eine gültige Signatur geringfügig zu ändern, um eine weitere gültige Signatur für dieselbe Transaktion zu erstellen. Diese Sicherheitsanfälligkeit verhinderte die Implementierung des Lightning Network. Die Absicht von Maxwell und Wuille mit SegWit war es daher, eine sichere Bereitstellung des Lightning Network zu ermöglichen und damit die Skalierbarkeitsprobleme von Bitcoin zu lösen. SegWit beinhaltete auch eine leichte und virtuelle Erhöhung der Blockgröße, während es gleichzeitig mit den alten Knoten kompatibel blieb (Soft Fork). Dieser Vorschlag wurde schnell zur Speerspitze kleiner Blocker.
Nach dem Scheitern von Bitcoin XT kamen Gavin Andresen und Jeff Garzik jedoch einige Wochen später mit einer neuen Idee zurück: Bitcoin Classic. Dieser Anfang 2016 vorgeschlagene Fork schlug einen gemäßigteren und einvernehmlicheren Ansatz als Bitcoin XT vor, mit einer Erhöhung der Blockgröße auf 2 MB (über BIP109). Die Initiative wurde von zahlreichen Unternehmen der Branche wie Coinbase sowie von Minern unterstützt.
Als Bitcoin Classic immer beliebter wurde und drohte, das Netzwerk zu spalten, wurde am 20. Februar 2016 eine Krisensitzung organisiert: die Runder Tisch in Hongkong. Diese Veranstaltung brachte Miner (darunter Jihan Wu und Micree Zhan, die Mitbegründer von Bitmain), einige einflussreiche Unternehmen und Bitcoin Core-Entwickler (darunter Luke Dashjr, Matt Corallo und Peter Todd) zusammen. Nach langen Verhandlungsstunden wurde eine Einigung erzielt. Core-Entwickler haben sich verpflichtet, einen Hard Fork für SegWit zu implementieren und das Blockgrößenlimit zu verdoppeln. Miner und Unternehmen versprechen ihrerseits, diesen Fork zu unterstützen und ausschließlich den Bitcoin Core-Client zu verwenden, um die Einheit des Bitcoin-Netzwerks zu wahren.
Dieser Deal sollte den Blocksize-Krieg beenden, führte aber letztendlich zu mehr Konflikten. Jede Seite hat das Abkommen anders interpretiert und es wird letztlich nie umgesetzt werden.
Einige externe Ereignisse schwächten diese Vereinbarung ebenfalls, insbesondere der Hack von The DAO auf Ethereum, der zu einem Hard Fork führte, um die gestohlenen Gelder zurückzuerhalten, was zur Spaltung zwischen ETH (Ethereum) und ETC (Ethereum Classic) führte. Dieser Hard Fork erwies sich für Ethereum als Katastrophe, insbesondere aufgrund der Replay-Attacken, die die gesamte Branche zum Erliegen brachten (Transaktionen von einer Blockchain konnten auf der anderen Blockchain identisch wiederübertragen werden). Dieses Fiasko verdeutlichte alle Risiken, die ein Hard Fork für Bitcoin darstellen könnte, und war daher ein wichtiges Argument für kleine Blocker, die sich in einer Position der Stärke befanden. Gleichzeitig haben andere Ereignisse den Ruf einiger großer Blocker getrübt, was ihre Glaubwürdigkeit in der Community geschwächt hat. Dieses Abkommen mit Hongkong hatte immer noch den Vorteil, die Dynamik von Bitcoin Classic einzudämmen.
Kleine Blocker machen sich diesen Ruf zunutze, um alleine SegWit-Reporting zu starten, indem sie einrichten, dass der Soft-Fork aktiviert wird, wenn 95% der Rechenleistung dies über einen bestimmten Zeitraum zulassen. In den ersten Wochen ist die Berichterstattung jedoch nach wie vor gering und Minderjährige scheinen nicht kooperieren zu wollen. Gleichzeitig gewinnt ein neuer Fork-Vorschlag bei Bitcoin Unlimited an Beliebtheit. Dieser alternative Kunde, der insbesondere vom Unternehmer Roger Ver (Spitzname „Bitcoin Jesus“) gefördert wird, schlägt vor, die Größe der Blöcke auf flexible Weise über eine Hard-Fork zu erhöhen. Im Gegensatz zu Bitcoin Classic legt Bitcoin Unlimited keine Obergrenze für die Blockgröße fest, sodass Benutzer ihre eigenen Einstellungen festlegen können.
Unter der Bedrohung durch diesen neuen Fork wurde BIP148 im März 2017 von einem anonymen Entwickler namens Shaolin Fry veröffentlicht. Das Ziel von BIP148 ist es, die Aktivierung des SegWit-Updates für das Bitcoin-Protokoll zu erzwingen, da die Signalisierung dieses Soft-Forks durch Miner über die klassische BIP9-Methode stagniert. Um dies zu erreichen, schlägt er die Implementierung eines UASF vor (Benutzeraktivierter Soft Fork), um SegWit am 15. November 2017 von den Nodes gewaltsam zu aktivieren, falls die Miner SegWit nicht bis zum 1. August 2017 gesperrt hatten. Wenn BIP148 von Benutzern verfolgt wird, lehnen Bitcoin-Netzwerkknoten Blöcke ab, die SegWit nicht unterstützen, wodurch Druck auf die Miner ausgeübt wird, das Update zu übernehmen.
Die Community sieht diesen UASF-Vorschlag als Chance, die großen Blocker endlich zu Fall zu bringen und beginnt daher, ihn aktiv zu unterstützen. Kleidung mit dem Akronym UASF taucht auf Konferenzen auf und die Kommunikation auf Twitter wird intensiviert.
Angesichts der Bedrohung durch die UASF sind die großen Blocker trotz ihrer starken Position gezwungen, an den Diskussionstisch zurückzukehren, nachdem SegWit nicht gemeldet wurde. So wurde am 23. Mai 2017 am Rande der Konferenz ein neues privates Treffen in New York organisiert Konsens 2017, das mehr als 50 Unternehmen aus dem Bitcoin-Ökosystem zusammenbringt. Aus diesem Treffen ging der SegWit2X-Vorschlag hervor, der zwei wichtige Änderungen am Bitcoin-Protokoll vorsieht:
Die Einführung von SegWit mit einer Aktivierungsschwelle von 80% der Signalisierung;
Ein Hard Fork zur Erhöhung der maximalen Blockgröße von 1 MB auf 2 MB.
James Hilliard (Ingenieur bei Bitmain) schlug dann BIP91 vor, um die Aktivierung der SegWit-Soft-Fork, definiert in BIP141, BIP143 und BIP147, über eine 80-prozentige MASF zu erleichtern. Diese Methode zielt darauf ab, BIP148 (UASF) überflüssig zu machen und eine mögliche Blockchain-Splittung am 1. August 2017 zu vermeiden. BIP91 wurde schließlich am 23. Juli 2017 (in Block 477.120) aktiviert, kurz vor dem von BIP148 festgelegten kritischen Datum, dem 1. August. Dies ermöglicht es, die Meldung von SegWit durch Minderjährige zu erzwingen. Das Programm wird schließlich am 9. August in Block 479 808 gesperrt und dann am 24. August in Block 481 824 aktiviert.
Das UASF ist also nie passiert, aber es spielte eine entscheidende Rolle bei der Einführung von SegWit, indem es die Miner zwang, den Soft-Fork über BIP91 zu sperren. Langfristig stellte BIP148 einen wichtigen Präzedenzfall dar und demonstrierte den Einfluss, den Benutzer über ihre gesamten Knoten auf die Entscheidungen zur Verwaltung des Bitcoin-Protokolls ausüben können, auch wenn große Unternehmen und Miner anderer Meinung sind.
Parallel zur Aktivierung von SegWit führt ein Teil der Bitcoin-Community am 1. August 2017 am Block 478 559 einen Hard Fork durch, um die Blockgröße auf 8 MB zu erhöhen. Dieser Split, genannt Bitcoin Cash (BCH), existiert heute noch neben Bitcoin, obwohl seine Bewertung im Vergleich dazu sehr niedrig ist.
Nach der Aktivierung von SegWit musste der zweite Teil von SegWit2X immer noch auf Block 494 784 implementiert werden, also im November 2017, über eine Hard Fork, die die Größe der Blöcke verdoppeln sollte. Kleine Blocker lehnten dieses Update jedoch entschieden ab, insbesondere weil es sich um eine Hard-Fork ohne alle notwendigen Sicherheitsmechanismen handelte. Eine neue Kommunikationskampagne mit dem Titel“ NEIN 2X “, tauchte dann auf, um diesen Anstieg der Blockgröße zu verhindern. Am 8. November wurde der Hard Fork in letzter Minute aufgrund mangelnden Konsenses und angesichts der Ablehnung durch die Community endgültig aufgegeben. Dieses Datum wird oft als das Ende des Blocksize-Krieges angesehen.
Diese Episode des Blocksize-Krieges hat zweifellos Spuren in der Bitcoin-Community hinterlassen. Was als einfache technische Debatte begann, entwickelte sich allmählich zu einem Konflikt, der die Existenz von Bitcoin hätte gefährden oder zumindest erheblich schwächen können. Diese Zeit beeinflusste auch die Art und Weise, wie Protokollentwicklungen entworfen wurden, tiefgreifend: Heute bevorzugt eine Mehrheit der Bitcoiner einen vorsichtigen und konservativen Ansatz bei Updates und bevorzugt Soft-Forks gegenüber Hard-Forks, auch wenn dies den Prozess verkompliziert. Darüber hinaus wird die Ideologie der kleinen Blocker inzwischen von den Nutzern weithin akzeptiert.
Der Blocksize War war auch ein Präzedenzfall, indem er zeigte, dass die UASF ein wirksames Abschreckungsinstrument sein könnte, das es Benutzern ermöglicht, ihre Macht angesichts von Minern und wichtigen Akteuren der Branche aufrechtzuerhalten.
Um dieses Thema von Blocksize War zu vertiefen, rate ich Ihnen, das Buch zu lesen Der Blocksize-Krieg von Jonathan Bier, mit dem ich diesen Artikel geschrieben habe.
.png)
.png)
.png)
.png)
.png)
.png)
