Weiter 1 MB? Oder 2? Oder doch gleich 8? Die Bitcoin-Kernentwickler diskutieren, wie man die Blocksize erhöhen kann. Mittlerweile gibt es vier konkrete Vorschläge, die zur Debatte stehen. Für die Szene sind die meisten von ihnen enttäuschend. Sie möchte am liebsten sofort sehr große Blöcke sehen, damit Bitcoin so viele Transaktionen wie möglich stemmen kann. Allerdings ist die Debatte nicht ganz so einfach …
So gut wie jeder kennt das Problem: Der Vertrieb will, dass die Produktion das Unmögliche wahrmacht, und mehr produziert, als die Fabrik hergibt. Der Bauherr möchte ein Haus, das günstig, riesig, wärmegedämmt ist und allen statischen Prinzipien widerspricht. Und so weiter. In jedem Projekt gibt es diejenigen, die verlangen und fordern, und es gibt diejenigen, die konstruieren und bauen. Meist widersprechen sich diese beiden Gruppen. Die einen wollen das maximal wünschbare, die anderen klären das Mögliche. Die einen greifen nach den Sternen, die anderen zum Maßband.
Bei der Entwicklung von Bitcoin-Core, der Kernsoftware des Bitcoins, ist es nicht anders. Die Community möchte, dass die Größe der Blöcke erhöht wird, damit der Bitcoin mehr Transaktionen stemmen kann. Eine Beschränkung auf 1 MB je Block – was 3-5 Transaktionen je Sekunde entspricht – ist nun mal zuwenig für ein Zahlungsmittel mit dem Anspruch, global zu funktionieren, Nanopayment zu ermöglichen und nebenbei als verteilte Datenbank den Wertpapierhandel und das Notarwesen zu revolutionieren. Daher sind sich an sich alle einig: Bitcoin muss lernen, besser zu skalieren.
Blöcke und ihre Größe
Blöcke sind die fundamentale Einheit der Blockchain genannten Technologie hinter dem Bitcoin. Die Miner fügen etwa alle zehn Minuten einen neuen Block mit aktuellen Transaktionen an die Blockchain an. Diesen neuen Block verteilen sie dann im Netzwerk, wodurch alle Teilnehmer dieselbe Blockchain mit denselben Blöcken haben. Eine Transaktion gilt erst als bestätigt, wenn sie in einen neuen Block aufgenommen und dieser an die Blockchain hinzugefügt ist. Ursprünglich war die Größe von Blöcken unlimitiert. Nachdem aber ein theoretischer Angriff gefunden wurde, haben die Entwickler die Größe von Blöcken auf 1 Megabyte beschränkt. Umgerechnet bedeutet dies, dass die Blockchain nicht mehr als 3-5 Transaktionen je Sekunde aufnehmen kann. Dieses Limit ist bis heute gültig. Lange Zeit war es kein Problem, doch die stark steigende Anzahl täglicher Transaktionen bringt das Bitcoin-Netzwerk immer öfter an sein Limit, weshalb der Ruf nach größeren Blöcken zunehmend laut wird.
Die Kernentwickler beschäftigen sich natürlich schon länger mit dem sogenannten Scalability-Problem. Während sie Bitcoin Core ständig weiterentwickeln (brillant mit der Version 0.11!), diskutieren sie verschiedene Lösungsansätze. Allerdings gehen die Ansichten, wie man Bitcoin skalierbar macht und wie groß künftig die Blöcke sein sollen, megaweit auseinander.
Während Kernentwickler Gavin Andresen konsequent und öffentlich für größere Blöcke plädiert, bleibt der Rest eher skeptisch mit einem unterschiedlichen Grad an Kompromissbereitschaft. Nun diskutieren die Kernentwickler in der Bitcoin-Mailing-List vier Vorschläge (Bitcoin Improvement Proposals, kurz: BIP) für eine Hard-Fork:
BIP100: Schlägt eine Hard Fork am 11. Januar 2016 vor, nachdem 90 Prozent der Miner zuvor zugestimmt haben. Die Blocksize soll zu diesem Zeitpunkt weiterhin 1 MB betragen, aber nach Übereinstimmung der Miner alle 3 Monate eine Erhöhung um den Faktor 0,5 bis 2 ermöglichen.
BIP101: Eine Hardfork soll frühestens am 11. Januar 2016 geschehen, nachdem 75 Prozent der Miner sie unterstützen. Die Größe der Blöcke soll sofort auf 8 MB springen, sich dann alle zwei Jahre verdoppeln, bis sie schließlich am 11. Januar 2036 8192 MB groß ist.
BIP102: Am 11. November 2015 soll eine Hardfork einsetzen, die die Größe der Blöcke auf 2 MB erhöht. Weitere Erhöhungen sind nicht vorgesehen.
BIP103: Schlägt eine HardFork am 1. Januar 2017 vor. Die Blocksize bleibt zunächst ebenso groß, steigt aber alle 97 Tage um 4,4 Prozent und wird 2063 die finale Größe von 2048 MB erreichen. Eine Steigerung von 17,7 Prozent im Jahr entspreche etwa dem Wachstum der Bandbreite.
Wer entscheidet, welcher Vorschlag umgesetzt wird?
Bitcoin ist Open Source, ja, was zunächst bedeutet, dass jeder den Code einsehen und nach Lust und Laune kopieren darf. Einen Push (= Write) Zugang zum Code auf GitHub hat allerdings nur eine sehr beschränkte Anzahl von Personen. Dies sind Wladimir J. van der Laan, Gavin Andresen, Jeff Garzik, Gregory Maxwell und Pieter Wuille. Nur diese Personen können den Bitcoin-Code verändern. Allerdings bekommen sie natürlich Hilfe von zahlreichen freiwilligen Entwicklern, die neue Versionen im Testnet testen und Vorschläge ausarbeiten.
Was allerdings jeder machen kann, ist, den Code zu forken und eine eigene Version aufzubauen. So hat Mike Hearn etwa Bitcoin XT von der Originalsoftware geforkt. Hearn hat bereits angekündigt, mit XT Gavin Andresens Vorschlag für 8 MB große Blöcke zu implementieren. Allerdings ist XT zum einen ein um Mike Hearn zentralisiertes Programm und es hat zum anderen viel zu wenig Anhänger, um Bitcoin Core als Standardsoftware abzulösen.
Ohne einen Konsens der fünf Kernentwickler wird es vermutlich keine gültige Erhöhung der Blocksize geben. Daher hängt nun alles davon ab, wie diese fünf Personen sich entscheiden. Gavin Andresen, Jeff Garzik und Peter Wuille haben bereits ihren Vorschlag eingereicht. Von Gregory Maxwell ist aufgrund vorheriger Äußerungen nicht zu erwarten, dass er eine Erhöhung der Blockgröße unterstützt, während Wladimir van der Laan als leitender Entwickler sich bislang mit konkreten Äußerungen weitgehend zurückhält.
Was spricht gegen eine Erhöhung der Blockgröße?
Während es sehr naheliegend ist, warum man größere Blöcke braucht – um mehr Transaktionen zu verteilen – sind die Argumente gegen eine Erhöhung der Blockgröße komplizierter und technologischer. Die Kernentwickler sehen ihre Aufgabe nicht darin, ökonomische Wünsche der Community zu erfüllen, sondern die Sicherheit des Systems zu gewährleisten. Und für dieses stellt nicht nur eine Hard Fork an sich ein großes Risiko dar, sondern auch die unkontrollierte Erhöhung der Blockgröße. Es gibt folgende technische Risikofaktoren:
- Der Bedarf an Festplattenspeicher führt zur weiteren Zentralisierung von Knoten. Man benötigt schon jetzt mehr als 30 Gigabyte Festplattenspeicher, um Bitcoin Core zu betreiben. Wenn man die Blockgröße auf beispielsweise 8 MB erhöht, kann sich diese Zahl sehr schnell vervielfachen. Ein DdoS-Transaktionen durch Spam-Attacken kann alle zehn Minuten 8 MB sinnlose Daten auf jede Festplatte übertragen, die die Blockchain speichert. Für institutionelle Anbieter und Rechenzentren ist dies kein Problem, für den einzelnen Benutzer jedoch schon.
- Der Bedarf an Bandbreite führt ebenfalls zu weiterer Zentralisierung. Jeder Knoten propagiert eingehende Transaktionen und Blöcke im Netzwerk. Bereits jetzt benötigt Bitcoin Core eine gewisse Menge an Bandbreite. Wenn nun die Blöcke größer werden, werden nicht nur mehr Transaktionen durch die Knoten laufen, sondern auch größere Blöcke, welche mehr Bandbreite benötigen, um verteilt zu werden. Zu große Blöcke könnten es für Menschen in strukturschwachen Gebieten (zum Beispiel im nicht-metropolen Großraum Nürnberg :)) unmöglich machen, einen Node zu betreiben. Es gibt verschiedene Hochrechnungen, wie hoch die benötigte Bandbreite sein wird und wie hoch die verfügbare Bandbreite in Zukunft ausfallen wird. Diese Hochrechnungen sind allerdings nicht eben valide und daher immer selbst ein Risikofaktor. Während Gavin Andresen sehr optimistisch rechnet, um die Blöcke möglichst groß zu kriegen, rechnet Pieter Wuille sehr konservativ, um das System keinen Risiken auszusetzen.
- Die Verzögerung der Propagierung von Transaktionen: Je größer die Blöcke sind, desto länger brauchen sie, um im Netzwerk propagiert zu werden. Auch hier fallen Hochrechnungen nicht eindeutig aus, aber es könnte sein, dass zum Beispiel 8 MB große Blöcke die Dauer so erheblich verlängern, dass Miner Gefahr laufen, mehr verwaiste Blöcke zu erzeugen, da sie „auf der falschen / alten Blockchain“ minen. Dies könnte die schwächeren Miner vom Markt verdrängen und die bereits bestehende ungünstige Zentralisierung des Minings weiter verschärfen oder gar den Angriff des „egoistischen Minings“ einfacher machen.
Für die Kernentwickler geht es vor allem darum, das System sicher und dezentral zu halten. Daher wollen sie konservative, vorsichtige Forks, mit der Option, im Falle des Erfolges später noch nachzujustieren, anstatt das System einen Risiko auszusetzen, um ein Problem auszumerzen, dass es so noch gar nicht gibt. Bei derzeit gut 100.000 Transaktionen am Tag ist eine zarte Erhöhung der Blocksize zwar angebracht, aber eine Verachtfachung ist noch nicht im Ansatz notwendig. „Wenn Bitcoin sehr groß skalieren muss, um erfolgreich zu sein, dann ist es bereits gescheitert“, wie es Pieter Wuille sagte. Wie einige andere Kernentwickler setzt er darauf, dass Bitcoin an sich sicher bleibt, während man die „totale Skalierbarkeit“ durch weitere Dienstleister wie Changetip oder Coinbase sowie Protokoll-Überschichten wie Lightning oder Sidechains erreicht. Der Bitcoin würde damit weniger zum digitalen Bargeld als zum Settlement-Netzwerk für darüber geschaltete Protokolle und Unternehmen.
Jemand andreres antwortete, man habe es noch nicht mal versucht, Bitcoin zu skalieren. Für viele Nutzer überdies soll Bitcoin bleiben wie er ist, anstatt zum Settlement-Netzwerk zu werden. Denn zentrale Zahlungsdienstleister gibt es schon genug.
Anders gesagt: die Diskussion wird uns wohl noch eine ganze Weile begleiten. Denn die Frage nach der Blockgröße ist nicht rein technologisch, sondern idealistisch. Es geht darum, was der Bitcoin sein soll.