Bitcoin Kernentwickler einigen sich auf Fahrplan für Skalierbarkeit

31 Bitcoin-Kernentwickler haben gestern einen „Fahrplan zur Skalierbarkeit“ unterzeichnet. Damit ist, zumindest aus Sicht der Kernentwickler, die Debatte um die Blockgröße beendet.

31 der aktivsten Kernentwickler haben gestern Gregory Maxwells Vorschlag zugestimmt, wie Bitcoin besser skalierbar gemacht werden soll. Damit kann eine für die Kernentwickler zunehmend anstrengende und zermürbende Debatte, ob man die Größe der Blöcke erhöhen soll, als beendet betrachtet werden. Der „Fahrplan zur Skalierbarkeit“ entspricht Maxwells Zusammenfassung der zweiten Scaling Bitcoin Konferenz. Er umfasst:

• Die Nutzung von libsecp256k1 für die Verifizierung, was die Synchronisierung der Clienten um 400% bis 700% beschleunigen und die CPU-Belastung für Knoten deutlich senken soll
• Eine Soft Fork für Segregated Witness (SG). SG soll die historischen Signaturen aus den Transaktionen entfernen und damit die Kapazität eines Blocks um 50-200% erhöhen. SG soll im Lauf der nächsten 3-6 Monate in den Clienten implementiert werden.
• Anschließend sollen weitere Updates wie IBLT und Weak Blocks (die die Gefahr von verwaisten Blöcken reduzierem) eingerichtet werden. Diese sind hilfreich, falls künftig eine Erhöhung der Blockgröße notwendig ist.
• Zunächst jedoch soll es für mindestens 1 Jahr keine Hardfork für größere Blöcke geben
• Stattdessen sollen noch 2016 sämtliche Updates implementiert werden, die die Einrichtung des Lightning-Nezwerkes ermöglichen. Dieses soll dann der Kanal sein, um kleine und schnelle Transaktionen zu versenden. Lightning ist laut den Kernentwicklern die echte Lösung für das Problem der Skalierbarkeit.

An dieser Stelle muss ich mich entschuldigen. Ich knalle euch Wörter um die Ohren – libsecp256k1, Segregated Witness, IBLT, Weak Blocks, Lightning – die ich selbst nicht vollständig verstehe. Ich werde jedoch diese Begriffe in den kommenden Wochen bzw. Monaten ausführlich erklären.

Eine technische Bewertung dieses Fahrplans kann ich nicht liefern. Dazu fehlt es mir an Kompetenz. Ich freue mich, dass die Kernentwickler zu einer Einigung gekommen sind und nun die Arbeit an einer Lösung den fruchtlosen, die Community trennenden Streit um die richtige Blockgröße ablöst. Zudem ist zu begrüßen, dass die Kernentwickler nicht einfach „nur“ die Größe der Blöcke erhöhen, sondern daran arbeiten, so viele Transaktionen wie möglich in die Blöcke zu pressen und den Weg bereiten, um gefahrlos die Größe der Blöcke zu erhöhen, falls notwendig. Man könnte es damit vergleichen, energiesparsamere Technologien zu entwickeln, anstatt ein neues Kraftwerk zu bauen.

Allerdings wird der Fahrplan von vielen kritisiert, und das meiner Ansicht nach nicht ohne Grund. Von allen genannten Updates wird lediglich Segregated Witness (SG) die Kapazität des Netzwerkes erhöhen. Da es für SG noch keinen Code gibt und auch noch keine Tests durchgeführt wurden, ist mit einer Implementierung frühestens Mitte 2016 zu rechnen. Zudem steht noch nicht fest, ob ein so tiefer Eingriff in den Kerncode des Bitcoins wie der Verzicht auf historische Transaktionen nicht unangenehme Nebenwirkungen haben kann.

Betrachtet man zudem, dass Bitcoin bereits jetzt am Limit kratzt und kontinuierlich 5.000 bis 15.000 Transaktionen auf eine Bestätigung warten, ist es zweifelhaft, ob eine kleine Erhöhung der Kapazität Mitte 2016 ausreichend ist. Möglich, dass der enge Flaschenhals bis dahin einen großen Schaden anrichtet. In jedem Fall begrenzt er das weitere Wachstum der Bitcoin-Anwendung. Viel mehr als derzeit wird bis Mitte 2016 nicht möglich sein. Ob das Lightning-Netzwerk am Ende tatsächlich die ersehnte totale, dezentrale und freie Skalierbarkeit bietet und gleichzeitig Betreibern von Bitcoin-Knoten einen finanziellen Anreiz gibt, oder ob es Bitcoin damit zu einer semi-dezentralen Währung wie Ripple macht, kann ich derzeit noch nicht entscheiden. Eventuell schaut ihr euch das Whitepaper an.

Ungünstig scheint mir auch, dass diese Lösung die Verfechter größerer Blöcke vor den Kopf stößt. Nachdem Gavin Andresen zuerst 20 MB und dann 8 MB vorgeschlagen und damit die Unterstützung von unter anderem Mike Hearn, Coinbase, BitPay, Slushs Pool und Bitstamp gefunden hat, brachte Jeff Garzik kürzlich BIP202 mit 2 MB und einem sehr langsamen weiteren Wachstum ins Spiel. Eine Erhöhung der Blocksize auf 2 MB wäre weit unter den ursprünglichen Vorschlägen gelegen, hätte die Zustimmung von Minern, Börsen, Zahlungsdienstleistern und Entwicklern gefunden und wäre ein Entgegenkommen gewesen, das die so stark geteilte Community dringend benötigt hätte. Dieses Zeichen der Einheit und des Kompromisses wurde mit dem Fahrplan leider verschenkt.

Update: Mittlerweile gibt es ein sehr aufschlussreiches FAQ zum Fahrplan. Mich als Autor beeindurckt die Balance zwischen Verständlichkeit und Tiefgang. Bitte unbedingt lesen.

Update 2: Heute erschien Bitcoin Unlimited, ein konkurrierender Client, der auf ein Blocksize-Limit vollkommen verzichtet. Seine Entwickler vertreten die Ansicht, der Markt würde das Limit von selbst setzen. Könnte auch interessant für alle sein, die mit der Lösung von Core nicht einverstanden sind.