Free Press

Die Zukunft der Blockchain-Serie

Der Kampf um eine skalierbare Lösung ist das Mondrennen der Blockchain. Bitcoin verarbeitet 4,6 Transaktionen pro Sekunde. Visa wickelt im Durchschnitt 1.700 Transaktionen pro Sekunde ab (basierend auf einer Berechnung, die von der offiziellen Angabe von über 150 Millionen Transaktionen pro Tag abgeleitet wurde). Das Potenzial für die Einführung ist vorhanden, wird aber derzeit durch die Skalierbarkeit behindert.

Eine von Tata Communications im Jahr 2018 veröffentlichte Studie zeigte, dass 44 % der befragten Unternehmen Blockchain einführen, spielt aber auch auf die universellen Probleme an, die bei der Einführung neuer Technologien auftreten. Auf architektonischer Ebene erweist sich das ungelöste Problem der Skalierbarkeit als Engpass für die Einführung und praktische Anwendung von Blockchain.

Wie Deloitte Insights feststellt, sind „Blockchain-basierte Systeme vergleichsweise langsam. Die langsame Transaktionsgeschwindigkeit von Blockchain ist ein großes Problem für Unternehmen, die auf leistungsstarke Legacy-Transaktionsverarbeitungssysteme angewiesen sind.“ Die Welt erhielt 2017 und 2018 einen Vorgeschmack auf die Skalierbarkeitsprobleme: schwere Übertragungsverzögerungen und hohe Gebühren im Bitcoin-Netzwerk und die berüchtigte Cryptokitties-App, die das Ethereum-Blockchain-Netzwerk (ein Netzwerk, auf das Tausende dezentraler Anwendungen angewiesen sind) verstopfte.

Um eine Blockchain zu skalieren, reicht es nicht aus, die Blockgröße zu erhöhen oder die Blockzeit durch Verringerung der Hash-Komplexität zu verkürzen. Mit beiden Methoden erreicht die Skalierbarkeit eine Obergrenze, bevor sie die Transaktionen erreicht, die notwendig sind, um mit Unternehmen wie Visa zu konkurrieren, das „durchschnittlich 150 Millionen Transaktionen pro Tag“ oder etwa 1.736 Transaktionen pro Sekunde (TPS) abwickelt.

Im Vergleich dazu sind die Transaktionsgeschwindigkeiten von Bitcoin enorm niedriger. Derzeit ist die Blockgröße auf 1MB festgelegt (1.048.576 Bytes – obwohl diese Größe durch SegWit auf bis zu theoretisch 4MB skaliert werden kann) und die durchschnittliche Transaktionsgröße beträgt 380,04 Bytes (unter der Annahme, dass jede Transaktion von einer Wallet zu x anderen Wallets erfolgt – eine Batch-Transaktion würde also als eine Transaktion zählen. Daher berechnet sich die durchschnittliche Anzahl der Transaktionen, die in einen Bitcoin-Block passen, derzeit wie folgt:

Die aktuelle Bitcoin-Block-Generierungszeit beträgt 10 Minuten, d.h., alle zehn Minuten wird ein neuer Block geschürft. In zehn Minuten (600 Sekunden) kann Bitcoin, basierend auf früheren Annahmen, durchschnittlich 2.759,12 Transaktionen durchführen. Mit anderen Worten, die Bitcoin-Blockchain kann derzeit nur 4,6 Transaktionen pro Sekunde garantieren.

Eine Erhöhung der Blockgröße oder eine Verringerung der Blockerzeugungszeit wird das Problem nicht lösen: Ein Blick auf die TPS von Non-SegWit

Das Problem der Skalierbarkeit kommt im Paket mit den Wertvorstellungen der Blockchain; daher kann man die Skalierbarkeit nicht einfach erhöhen, indem man Parameter in der Blockchain ändert.

Die Bitcoin-Gemeinschaft kann zwei Variablen anpassen, um zu versuchen, die TPS zu erhöhen. Eine Variable ist die Blockgröße (B), die derzeit fest auf 1MB kodiert ist. Idealerweise sollte B erhöht werden, um die TPS zu steigern. Die andere Variable ist die Blockerzeugungszeit (TB), die durch Änderung der Komplexität des Hash-Puzzles angepasst wird. Im Idealfall sollte TB verringert werden, um die TPS zu erhöhen.

Szenarien 1 & 2

Um von 4,4 auf die 1.736 von Visa zu wachsen, müsste Bitcoin seine TPS um das 377,5-fache erhöhen. Mit anderen Worten: B müsste von 1 MB auf 377,5 MB erhöht werden (Tabelle 1, S1) oder TB müsste von zehn Minuten auf 1,6 Sekunden reduziert werden (Tabelle 1, S2). Ein drittes Szenario wäre die Anpassung von beidem. Jedes der drei Szenarien ist auf der Blockchain aufgrund eines dritten, unkontrollierten Faktors unerreichbar: die Relay Time (TR), die benötigt wird, um einen neuen Block an jeden Knoten im Bitcoin-Netzwerk zu senden.

Zurzeit gibt es schätzungsweise 10.198 Knoten im Bitcoin-Netzwerk. Die Übertragung eines 1MB (1.048.576 Bytes) durch das Peer-to-Peer-Netzwerk dauert einige Zeit. Das Karlsruher Institut für Technologie misst die Blocklaufzeit von Bitcoin, und die durchschnittliche Blocklaufzeit, die am 17. Januar 2019 gemeldet wurde, betrug 13.989,42 Millisekunden oder etwa 14 Sekunden, um sich zu 99 % des Netzwerks zu verbreiten. TB kann nicht unter 99 % von TR (TR99)=14 fallen, da in diesem Fall ein neuer Block erzeugt würde, bevor ein alter Block von den meisten Blöcken im Netz empfangen würde. Je näher TB an TR99 herankommt, desto mehr Probleme treten mit Forks, verwaisten Blöcken und Kettenumstrukturierungen auf und (in extremen Fällen) mit Sicherheitslücken wie Double-Spend-Angriffen.

Szenario 3

Selbst wenn TB = TR99 = 14 wäre, könnte die Bitcoin-Blockchain bei einer Blockgröße von 1MB ihre Geschwindigkeit nur auf 188 TPS steigern (Tabelle 1, S3). Diese Größenordnung stellt zwar eine 188-fache Steigerung der TPS dar, reicht aber bei weitem nicht an die 1.736 TPS heran, die Visa täglich durchführt, und birgt darüber hinaus die bereits erwähnten Risiken. Die andere Variable, B, kann angepasst werden, jedoch nicht ohne Auswirkungen auf TR, was sich auf TR99 und damit auf die Untergrenze von TB auswirken würde.

Szenario 4

Bei einer Verdoppelung der Größe von B (von 1MB auf 2MB) würde sich beispielsweise die Zeit, die jeder Knoten im Netz zum Herunterladen eines neuen Blocks benötigt, TR, ebenfalls erhöhen – und zwar um etwa das Doppelte; bei 2MB wäre TR99 also 28s, so dass die Untergrenze von TB ebenfalls 28s betragen würde. Erhöht man B um einen beliebigen Faktor und erhöht anschließend TR um denselben Faktor, so bleibt die Netto-TPS gleich – in diesem Fall etwa 188 TPS (Tabelle 1, S4). Eine Lösung, um die Auswirkungen von B auf TR zu verringern, besteht darin, die Bandbreite zwischen allen Knoten im Bitcoin-Netzwerk zu erhöhen. Da es sich um ein P2P-Netzwerk handelt, fällt diese Verantwortung leider in den Schoß eines jeden Peers im Netzwerk.

Das Aufkommen von SegWit

Im Jahr 2017 wurde Segregated Witness (SegWit) für alle Bitcoin-Knoten in Kraft gesetzt. Hinweis – Ich werde nicht auf alle Details von SegWit eingehen, aber wenn Sie etwas über seine Geschichte und seine Rolle bei der Entstehung des Bitcoin Cash Hard Forks erfahren möchten, werfen Sie einen Blick auf diesen Artikel:

Es tut das, wonach der Name klingt – es trennt den Zeugen-Teil jeder Transaktion von den eigentlichen Transaktionsdaten. Es handelte sich um einen Soft Fork, d.h. er wurde ohne größere Auswirkungen auf das bestehende Blockchain-Netzwerk und den Code eingeführt. Aufgrund der Art und Weise, wie die Zeugen-Transaktion gewichtet wird, könnten die neuen SegWit-fähigen Bitcoin-Blöcke theoretisch auf bis zu 4 MB vergrößert werden, ohne die Bitcoin-Blockgröße zu verändern.

Ich sage theoretisch, weil es zusätzliche Faktoren gibt, die zur endgültigen Größe des SegWit-Blocks beitragen. In der Tat, wenn Sie einen Bitcoin-Blockchain-Explorer überprüfen, werden Sie sehen, dass (zumindest zum Zeitpunkt der Veröffentlichung dieses Artikels) die durchschnittliche Blockgröße immer noch unter 1MB liegt.

Das heißt aber nicht, dass Blöcke nicht mehr als 1 MB groß sein können. Anfang 2018 wurden wir Zeuge einer der größten (wahrscheinlich immer noch größten) generierten Blockgrößen, die rund 2,1 MB wog. Der Soft Fork von SegWit hat dazu beigetragen, die Blockgröße ohne Änderungen am Kerncode zu verbessern, aber er verbessert die TPS immer noch nicht auf skalierbare Weise.

Bei der Untersuchung der vorherigen vier Szenarien unter einem Proof-of-Work-Konsens haben wir gesehen, dass eine einfache Erhöhung der Blockgröße oder eine Verringerung der Mining-Komplexität uns nur so weit bringen kann. Selbst eine Kombination aus beidem wäre aufgrund der Transaktionsausbreitungszeit nur begrenzt möglich. Der Versuch, neue Blöcke schneller zu schürfen, als sich alte Blöcke ausbreiten können, führt zu einigen ziemlich großen Sicherheitsproblemen. SegWit hat dazu beigetragen, einige der TPS-Probleme in der Zwischenzeit zu lindern, aber es wird immer noch eine skalierbarere Lösung benötigt, um eine Visa-ähnliche TPS zu erreichen.

Es scheint, dass jedes Teil, das zur Erhöhung der TPS eingesetzt wird, ein anderes Teil an einer anderen Stelle des Blockchain-Puzzles verschiebt; unabhängig davon gibt es Projekte und Startups, die daran arbeiten, die TPS-Antworten zu erreichen, die benötigt werden, um die Blockchain-Einführung in ein skalierbares Stadium zu bringen.

Bestehende und künftige Ansätze zur Lösung des Skalierbarkeitsproblems

Bei der Suche nach einer potenziellen Antwort auf das Skalierbarkeitsproblem ergeben sich mehrere andere Fragen. Wenn die Antwort beispielsweise nur für eine bestimmte Blockchain gilt, dann beruht sie auf der Annahme, dass diese Blockchain diejenige ist, die diese Skalierbarkeit in der Zukunft benötigt; andernfalls ist der Aufwand unangemessen oder fehl am Platz. Eine weitere Überlegung besteht darin, zu verstehen, was der Kompromiss sein könnte. Derzeit sind alle verfügbaren Lösungen mit Einschränkungen verbunden.

Zahlungen in einer Transaktion bündeln

Pros: Verringert die Größe eines Transaktionsdatensatzes, indem mehrere Transaktionen in einer zusammengefasst werden, was insgesamt mehr Transaktionen pro Block ermöglicht, was die TPS bis zu einem gewissen Grad erhöhen kann.

Nachteile: Kann die Transaktionen mehrerer Wallets nicht zusammenfassen; gefährdet die Privatsphäre

Batch-Zahlungen sind ein Merkmal von Bitcoin (und daher auch der Bitcoin-Forks, einschließlich Digibyte, Dogecoin, Bitcoin Cash usw.) durch die RPC Sendmany gewesen. Exchanges tun dies bereits, und Sie können es sehen, wenn Sie versuchen, Ihre Transaktions-ID auf einem Blockchain-Explorer nachzusehen. Es kann sein, dass eine Wallet an mehrere verschiedene Wallets sendet. In diesem Fall handelt es sich um eine Stapeltransaktion.

Der Vorteil dieser Vorgehensweise ist, dass Sie nur eine Transaktionsgebühr zahlen müssen und nicht für jede Transaktion eine vollständige Transaktion schreiben müssen, die, wie ich zuvor beschrieben habe, etwa 380 Byte umfasst. Tatsächlich sind von den 380 Bytes, die die Transaktion umfassen kann, nur 34 Bytes die Transaktionsinformationen.