Diese zwei Features mit den seltsamen Namen sind Schlüsseltechnologien, um Bitcoin zu skalieren. libsecp256k1 wird im nächsten Core-Release OpenSSL dabei ersetzen, Transaktionen zu verifizieren – und die Geschwindigkeit dieses Vorgangs um das bis zu fünffache erhöhen. ThinBlocks hingegen wurde von Bitcoin Unlimited entwickelt und beschleunigt das Propagieren von Blöcken enorm.
Manchmal trifft man in der ganzen Debatte um Blockgröße, Skalierbarkeit und Kapazität auf Aussagen wie diese: „Eine Erhöhung der Blockgröße skaliert, verbessert aber nicht die Skalierbarkeit.“Das ist nicht nur ein Wortspiel, das schlau klingt, sondern bedeutet, dass man zwar tatsächlich mehr Transaktionen durch das Netzwerk jagen kann, wenn man wie so oft gefordert die Größe der Blöcke erhöht, aber dies nicht im geringsten die Fähigkeit des Netzwerkes verbessert, mit mehr Transaktionen umzugehen.
Eine Erhöhung der maximalen Blockgröße auf mehr als 1 MB mag notwendig sein, um weiteres Wachstum zu ermöglichen. Aber sie ändert nichts an dem Problem, dass mehr Transaktionen mehr CPU brauchen, um verifiziert, mehr Bandbreite, um propagiert, und mehr Festplatte, um gespeichert zu werden. Diese drei Anforderungen – CPU, Brandbreite, Festplatte – an einen Bitcoin-Node begrenzen die Skalierbarkeit. Sie sorgen dafür, dass das Netzwerk, wenn man weit genug skaliert, irgendwann zu einem Netzwerk von Supernodes in Datenzentren wird. Normale Computer können nur noch indirekt Verbindung zu Bitcoin aufnehmen.
Weniger Bandbreite mit Thinblocks
Zum Glück gibt es jedoch Möglichkeiten, auch die Skalierbarkeit des Bitcoins zu verbessern. Eine davon ist Extreme Thinblocks und wurde vom Bitcoin Unlimited Team entwickelt. Um zu erklären, was „xthin“ macht und warum dies grandios ist, muss ich ein Stück ausholen.
In der Debatte um die maximale Größe der Blöcke wurde argumentiert, dass größere Blöcke sowohl für Miner als auch Nodes anstrengend sind. Miner finden Blöcke, stopfen Transaktionen in diese und verbreiten sie im Netzwerk. Das Problem ist, dass die Dauer des Propagierens exponentiell mit der Größe der Blöcke wächst. Ein 8 MB Block würde etwa mehr als 10 Minuten brauchen, um 1.000 Nodes zu erreichen. Wenn in dieser Zeit ein anderer Miner denselben Block findet und verteilt – was recht wahrscheinlich ist – wird der eigene Block ungültig und man erhält keine Belohnung. Dies nennt sich dann verwaister Block. Noch schlimmer wird die Lage, wenn man bedenkt, dass viele Miner in China und damit hinter der „Great Firewall“ sind, was die Verbreitung der Blöcke weiter verlangsamt. Angesichts dieser Schwierigkeiten werden Blöcke mit mehr als 2 MB derzeit als problematisch betrachtet.
Nodes hingegen empfangen die Blöcke und geben sie an andere Nodes – ihre peers – weiter. Im Datenstrom eines Nodes, der kontinuierlich Transaktionen empfängt und weiterleitet, sind die Blöcke die Spitzen. Wenn mein Node einen 1 MB block bekommt und an 8 peers weitergibt, muss er in möglichst rascher Zeit 8 MB in Netzwerk hochladen. Da die Upload-Kapazität von gewöhnlichen Internetverbindungen oft auf 2 oder 10 MB / Sekunde begrenzt ist, wird es für viele Nodes schon bei 1 MB Blöcken schwierig, diese schnell genug an alle peers zu verteilen, damit das Netzwerk synchron bleibt. 2 MB Blöcke würden schon jetzt viele Nodes an die Grenzen ihrer Kapazität bringen, von 8 MB Blöcken ganz zu schweigen.
Aus diesen beiden Gründen gilt die Anforderung an die Bandbreite als größtes Hindernis bei der Erhöhung der Blockchain und als eines der größten Probleme der Skalierbarkeit.
Xtreme Thinblocks löst dieses Problem nun, indem die Miner nicht mehr die gesamten Blöcke propagieren, sondern nur noch den Block-Header, in denen die kryptographische Hash enthalten ist, die den Block gültig macht. Die Nodes, so die Theorie, haben die Transaktionen in den Blöcken ja bereits empfangen. Sollte ihnen eine Transaktion fehlen, können sie diese vom Netzwerk oder von den Minern anfordern. So schlüpfen die Blöcke nicht nur leichtfüßiger durch die Great Firewall und verbreiten sich erheblich schneller im Netzwerk; mit thinblocks erfahren die Nodes zudem eine enorme Entlastung, da sie jede Transaktion nur einmal anstatt zweimal empfangen und weiterleiten. Die verbleibenden Daten verteilen sich gleichmäßig auf den Strom der Transaktionen, die Spitzen durch die Blockpropagierung fallen weg.
Xtreme Thinblocks wurde von den Entwicklern von Bitcoin Unlimited gebaut und wird wohl Teil des nächsten Releases meines Lieblings-Client sein. Die ersten Tests mit den Thinblocks wurden bereits erfolgreich zu Ende gebracht und haben die gesendeten Nachrichten im Netzwerk auf 1/13 reduziert. Exzellente Aussichten, und sollte kein Fehler mehr auftauchen, gibt es keinen Grund, weshalb nicht auch Core und Classic das Feature aufnehmen.
Weniger CPU-Belastung mit libsecp256k1
Thinblocks helfen auch bei einer zweiten Problemzone – der CPU. Nodes beanspruchen die CPU, wenn sie die Signaturen von Transaktionen verifizieren. Je nach Größe, Dichte und Struktur der Transaktionen kann dies bei schwächeren CPU oder bei Raspberries zur Belastung werden. Generell reduziert es die Fähigkeit schwächerer Nodes, größere Blöcke zu verarbeiten. Da Nodes mit Thinblocks jede Transaktion nur noch einmal anstatt wie bisher zweimal empfangen und verifizieren, wird die Belastung des Prozessors auf die Hälfte reduziert. Das ist schon mal gut.
Noch besser ist aber libsecp256k1. Um das zu verstehen, muss man wissen, dass Nodes eine kryptographische Bibliothek benutzen, um die mit ECDSA – einer auf elliptischen Kurven basierenden kryptographischen Funktion – signierten Transaktionen zu validieren. Bisher benutzen die Nodes hierfür OpenSSL. Dies ist eine Bibliothek (library) für Kryptographie und enthält unter anderem digitale Signaturen und Methoden, um Zufallszahlen zu generieren. OpenSSL ist eine allgemeine Bibliothek, sozusagen ein Allrounder, und wird in Core 0.12 durch libsecp256k1 ersetzt. Libsecp256k1 benutzt Signaturen auf einer bestimmten elliptischen Kurve, was die Verifizierung erheblich schneller macht. Laut den Core-Entwicklern beschleunigt das neue Krypto-Tool die Verifizierung um 200 bis 500 Prozent.
Libsecp256k1 ist vor allem in einem Bereich wichtig, in dem Thinblocks nichts helfen – in der initialen Synchronisierung eines Nodes. Denn ein Nodes muss, bevor er betriebsbereit ist, die gesamte Blockchain herunterladen und jede einzelne Transaktion verifizieren. Dies dauert, je nach CPU, lange bis extrem lange. Während thinblocks hier nichts ändern, beschleunigt libsecp256k1 diesen Prozess enorm.
Keine Monster-Transaktionen mit SegWit
Zuletzt sollten wir noch über Monstertransaktionen reden. Es ist möglich, bereits jetzt Transaktionen zu schreiben, die so viele und so große Signaturen haben, dass normale CPUs minutenlang brauchen, um sie zu validieren. Der Grund: Die Signaturen in den Inputs einer Transaktion signieren die gesamte Transaktion. Je größer eine Transaktion also ist, umso größer die Signatur. Wenn wir nun größere Blöcke zulassen, wird es möglich sein, noch größere Transaktionen zu schreiben, die noch länger bauchen, um validiert zu sein. Dies würde bereits bei 2 MB viele Nodes einfrieren und bei 8 oder mehr MB einen großen Schaden im Netzwerk anrichten. Ein wiederholter Angriff durch solche Transaktionen könnte die Anzahl der Nodes deutlich und dauerhaft reduzieren.
Classic löst dieses Problem auf eine effektive, aber wenig elegante Art: indem es die Größe einer Transaktion und die zu validierenden Signaturen beschränkt. Eleganter ist Segregated Witness, das im Lauf der kommenden Monate Teil von Core werden soll: Es schiebt die Signaturen in ein Witness außerhalb des Blocks, wodurch die Transaktion an sich kleiner und der Aufwand, Signaturen zu verifizieren, geringer wird. Dies verhindert nicht nur, dass komplexe Transaktionen zu Monster-Transaktionen werden, sondern senkt auch den CPU-Bedarf eines Nodes generell, da es die Validierung der Signaturen vereinfacht.
Endlose Kapazität?
All das, was ich hier beschrieben habe, ist tief-technisch. Falls ich als technischer Flachbohrer auf dem Holzweg bin oder radikal falsch gedacht habe, teilt es mir und den anderen Lesern bitte in den Kommentaren mit. Ansonsten wage ich zu behaupten, dass die hier vorgestellten Skalierbarkeits-Verbesserungen ein riesiges Potenzial haben und Blöcke in Größenordnungen von 10-20 MB ermöglichen können. Wie Bitcoin-Classic auf 2 MB zu forken ist demnach zu klein gedacht und im Vergleich mit anderen Lösungen wie Unlimited oder Bitcore vielleicht auch eine Vergeudung einer Hardfork.