Thinblocks und libsecp256k1 – echte Verbesserungen der Skalierbarkeit

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.

About Christoph Bergmann (880 Articles)
Das Bitcoinblog wird von bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder. Wenn Ihnen das Blog gefällt, freuen wir uns über Spenden an 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Jeder Satoshi wird dazu verwendet, um das Blog besser zu machen. Weitere Infos, wie Sie uns unterstützen können, finden Sie HIER. Gastbeiträge sind ebenfalls willkommen. Meinen öffentlichen PGP-Schlüssel sowie den Bitmessage-Schlüssel finden Sie HIER

12 Comments on Thinblocks und libsecp256k1 – echte Verbesserungen der Skalierbarkeit

  1. Wie sieht es aus, wer übernimmt diese Features? Nur Bitcoin-Classic? Wird damit jetzt die Community zusammen gebracht oder weiter getrennt? Gibt es auch Namenhafte Stimmen die diesen Features kritisch gegenüberstehen?

    Kurz: Wie wirkt sich das auf den Client wirr war und die angespannte Lage aus?

  2. Hier nochmal eine Englischsprachige Graphik ueber die neueste roadmap for Bitcoin:

    ..finde das passt ganz gut zu Ueberschrift, aber sonst einfach entfernen.

    LG, Tat Twam Asi.

  3. Nattydraddy // 20. February 2016 at 12:10 // Reply

    “Xtreme Thinblocks wurde von den Entwicklern von Bitcoin Unlimited gebaut und wird wohl Teil des nächsten Releases meines Lieblings-Client sein.”

    Bitcoin Unlimited hat eine Außenseiterrolle. Propagieren von Blöcken kann es gut, aber wer macht Propaganda für Bitcoin Unlimited?

    “Classic löst dieses Problem auf eine effektive, aber wenig elegante Art… Eleganter ist Segregated Witness, das im Lauf der kommenden Monate Teil von Core werden soll”

    Classic bietet etwas an, was jeder versteht: Das Blocksizelimit verdoppeln. Bei Segregated Witness streiten sich die Leute immer noch, was es in der Praxis bringt.

    Ich ünterstütze Core mit ihren Vorschlägen und ihrer (impliziten) Ansicht, dass die Verbesserungen technisch fundiert sein müssen. Das führt aber dazu, dass auch ich mich als “technischer Flachbohrer” empfinde.

    Besser geht es da Dilletanten: Sie haben so wenig Ahnung, dass sie noch micht mal wissen, dass sie ahnungslos sind. Das gibt einem genügend Selbstvertrauen, um alles zu verbessern. Bis man merkt, dass man die Karre gegen die Wand gefahren hat…

  4. Wieder mal ein, wie ich finde, super guter Artikel. Danke Christoph!
    Leider kann ich mit meinen bescheidenden Detailkenntnissen weder zustimmen noch dementieren aber wenn das alles so wie oben zu lesen stimmig sein sollte, wovon ich erst mal ausgehe, dann ist “die Sache” ja doch nicht so verloren wie man manchmal denken könnte🙂
    Go Protokoll GO!

  5. Dies ist der richtige Link zur Beschreibung:
    https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/

    Ein wesentliches Features ist der Bloomfilter, der bereits bei der Anfrage angibt, welche Transaktionen sich bereits im Mempool befinden und welche sofort im gleichen Schritt mit dem Thinblock mitgeliefert werden müssen. So hat man meisstens nur einen Roundtrip, was besonders im TOR Netz wichtig ist, denn dort sind die Ping Zeiten sehr lang.

    Dies wird auf jeden Fall ein guter Ersatz für das Block Relay Network, unabhängig ob Core es implementiert oder nicht. Das Core Team sollte das auf jeden Fall einmal ansehen und gut prüfen, ob es Probleme mit der malleability geben könnte(es basiert ja sehr auf TX Hashes) und wie es mit SegWit zusammenarbeiten kann.

  6. Ob das mit ein Grund für den aktuellen Preisanstieg ist? hmmmm….

    • Der ist vermutlich eher auf die Hardfork-nach-Segwit Einigung am runden Tisch in Hongkong zurückzuführen.

  7. Viele tolle Ideen, doch in der Realität haben wir JETZT bereits das Limit erreicht, benötigen wir JETZT eine Lösung der Problematik und nicht jede Woche neue Ideen, welche nicht zeitnah released werden.
    U.a. zeigt sich diese allein an diesem Wochenende, wo wir trotz Wochenende und eigentlich dadurch bedingt geringerer Traffic ziemlich nahe am Blocksizelimit sind. Da brauchen wir nur mal innerhalb der Woche eine richtige Rally erleben und dann wird das Bitcoinnetzwerk nahe daran sein zu kollabieren und sich der MemPool bereits JETZT aufblähen. D.h. wir sind momentan in einer Situation, in denen bereits eine Rally das Netzwerk zum Überlauf bringen würde.

    Und genau deshalb sind die 2MB die Classic vorschlägt eben alles Andere als unklug (zumal eine Erhöhung so oder so irgendwann kommen wird).
    Damit kann entsprechend der Druck aus dieser Debatte genommen und den Ideen die nötige Zeit gegeben werden, damit diese ausreichend getestet und dann ohne jeden Druck released werden können.

    Classic hat ja zudem bereits angekündigt, eine Vielzahl der Ideen zu übernehmen und eben nicht wie es der Eindruck vermittelt, das Rad selbst neu erfinden zu wollen.

    Des Weiteren halte ich die Herangegehens etwas falsch, nämlich die Ressourcenerhöhung nahezu radikal bekämpfen zu wollen.

    Eine Ressourcenerhöhung stellt KEIN Problem dar, weil sich die Industrie entsprechend darauf einstellt bzw. höhere Ressourcen anbietet.
    Technologisch bestehen bereits Lösungen für die Ressourcenproblematik, nur werden diese Lösungen nicht angeboten, u.a. weil eben die Nachfrage danach nicht existiert.
    Ja im Grunde sehnt sich die Industrie nach solch neuen Anforderungen, weil PC/Smartphone/Tablet usw. in ihrer Entwicklung momentan stagnieren und der Bedarf nach mehr Power und Speicher nicht existiert, worunter die Industrie mittlerweile ziemlich leidet.

    Gebt der Industrie die Nachfrage statt die Blockchain zu sehr zu verbiegen.

    Technologisch existieren Lösungen mit denen man eine Übertragungsrate von

    .125.000 MBit/s
    oder
    1125 GBit/s.

    http://www.trendsderzukunft.de/1-125-terrabit-pro-sekunde-neuer-weltrekord-bei-der-datenuebertragung/2016/02/15/

    • und was bringt die Speed, nix

      Das langsamste Glied bestimmt die Geschwindigkeit.

      Und das ist nunmal die Great-Wall in China, weil dahinter sich ein Großteil der Miner tümmelt.

      • Das ist das Problem chinesischer Miner aber nicht des Bitcoinnetzwerkes generell.
        Ich finde es bedenklich, wie die Entwicklung des Bitcoin bereits jetzt von einigen wenigen großen Instanzen bestimmt wird. Da stellt sich ernsthaft die Frage, worin der Unterschied zum klassischen Fiatgeldsystem ist.

  8. “Besser geht es da Dilletanten: Sie haben so wenig Ahnung, dass sie noch micht mal wissen, dass sie ahnungslos sind. Das gibt einem genügend Selbstvertrauen, um alles zu verbessern. Bis man merkt, dass man die Karre gegen die Wand gefahren hat…”

    gefaellt mir und passt auf so vieles…

1 Trackback / Pingback

  1. Bitcoin Unlimited 0.12 ist erschienen – BitcoinBlog.de – das Blog für Bitcoin und andere virtuelle Währungen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s