This post is also available in: English

Dieser Beitrag ist der letzte einer fünfteiligen Serie, die sich mit dem Velocity-Protokoll beschäftigt. Die früheren Beiträge sind hier zu finden:

Bloom-Filter
Invertierbare Bloom Lookup Tables (IBLTs)
Grapheneprotokoll
Giftblock-Angriffe

Das Velocity-Protokoll wurde von Wissenschaftlern des Blockchain-Labors der Arizona State University entwickelt. Es ist gleichzeitig Gegenstand der Masterarbeit des ASU-Absolventen Nakul Chawla.

Als Zusammenfassung der letzten Beiträge lässt sich sagen, dass die Protokolle Compact, Xthin und Graphene Blöcke im ganzen Netzwerk verbreiten, indem sie eine Liste der Transaktionen eines Blocks weiterreichen. Hierdurch wird sehr viel Bandbreite gespart, da der 8-Byte-Identifikator Transaktionen mit Hunderten oder Tausenden Bytes ersetzen kann. Wir sprachen zudem darüber, wie Graphene mehr Effizienz durch bestimmte Datenstrukturen erreicht und welche Protokolle von Giftblockangriffen ausgehebelt werden können. Diese Angriffe können dann entstehen, wenn Miner Blöcke mit Transaktionen senden, die zuvor nicht an das Netzwerk übertragen worden waren.

Bandbreiteneffizienz maximieren statt Bandbreitenanforderung reduzieren

Das Velocity-Protokoll wagt sich an eine völlig neue Herangehensweise, die von der Existenz des Masternode-Netzwerks profitieren wird. Das Velocity-Protokoll versucht nicht die benötigte Bandbreite zu reduzieren, stattdessen will es die vorhandene Bandbreite effizienter nutzen. Bandbreite ist eine Ressource, die man entweder nutzt oder verschwendet. Ein Rechenzentrum kann seine Leitung mit 1 GB/s entweder immer oder nur zu bestimmten Zeiten nutzen. Die Kosten sind in beiden Fällen die gleichen.

Um das Velocity-Protokoll zu erklären, möchte ich auf ein paar Zahlen verweisen. Die Grundidee besteht darin, dass ein Block in Symbole zerlegt wird, wobei wir in diesem Fall von 1000 Symbolen sprechen. Sagen wir eine Node fragt ihre 25 Peers nach dem Block, wobei 14 ihn bereits kennen und daher damit beginnen, der Node die Symbole zu senden. Die Node erhält nun 995 Symbole und zusätzlich 5 Reparatursymbole. Hierdurch kann sie den ganzen Block mit ziemlich hoher Sicherheit selbst aufbauen. Da der ganze Block wiederhergestellt wird, ist das System somit immun gegen einen Giftblockangriff. Die Simulationen, welche Nakul Chawla durchgeführt hat, deuten darauf hin, dass dieses Protokoll sehr effizient funktionieren wird. Wir sind der Ansicht, dass dies der parallelen Nutzung der Bandbreite geschuldet ist.

Auswirkung technisch-schwacher Nodes wird minimiert

Das Velocity-Protokoll minimiert zudem die negativen Auswirkungen, welche eine Node mit geringer Bandbreite mit sich bringt. Ein Block, der über eine schlechte Verbindung angefordert wird, sorgt normalerweise für eine Verzögerung der Übertragung. Nehmen wir an, dass eine Node mit fünf anderen verbunden ist (A, B, C, D, E) und davon D und E nur über eine schlechte Verbindung verfügen. A und B stellen nun jeweils 350 Symbole bereit, während C 200 und D & E jeweils 50 bereitstellen. Dies heißt, dass D und E zur Beschleunigung des Netzwerks beitragen, auch wenn dies nur in geringem Maße geschieht. Ohne Aufteilung der Bandbreitenbelastung würde die schwache Verbindung der Nodes hingegen für eine Verlangsamung sorgen.

Manche Entwickler sagen, dass Bitcoin so robust sei, wie seine schwächste Node. Diesem Ansatz widerspricht der Entwickler Peter Rizun von Bitcoin Unlimited deutlich. Er sagt, dass ein C64 das Netzwerk nicht belasten würde, da er stattdessen nach einiger Zeit abgestoßen würde. Durch Velocity könnten Bitcoin, Dash und andere Netzwerke selbst die schwächsten Nodes noch für sich arbeiten lassen, während diese ebenfalls effektiver unterstützt werden. Das Netzwerk profitiert also in jedem Fall vom Wachstum der Node-Anzahl.

Konkurrenz zu VISA als bekannter Vergleich

Kurz gesagt sind wir von dem Ergebnis unserer Simulation begeistert. Doch bis wir den Simulations-Status verlassen können, ist es noch ein weiter Weg. Es gibt durchaus Faktoren, die einer direkten Implementierung im Weg stehen.

Für uns gibt es zwei Grenzen, die wir beachten müssen, wenn es um die Skalierung dieser Netzwerke geht. Die erste Grenze ist jene, bei der der Netzwerk-Konsens verloren gehen würde. Vorher kommt jedoch bereits die wirtschaftliche Grenze, ab der es für Miner keinen Sinn machen würde, größere Blöcke zu schaffen. In unserer Simulation kann Dash eine Konsensgrenze von 500 MB erreichen, wobei die wirtschaftliche Grenze bereits bei ca. 300 MB gezogen würde. Dies würde also bedeuten, dass Dash mit ca. 250 MB die durchschnittlichen Transaktionen von VISA verarbeiten könnte. Das wäre fantastisch!

Vergleich zur Gigablock-Forschung auf dem Testnet

Mit unserer Forschung verwandt ist jene von Peter Rizun, Andrew Stone, et al., die davon ausgehen, dass Bitcoin 1 GB-Blöcke erreichen könnte, bevor der Konsens verloren geht. Unser Ergebnis ist, dass Dash 500 MB Blöcke unterstützen kann, was durch die kürzere Blockzeit auf die doppelte Zahl an Transaktionen hinauslaufen würde. Die beiden Versuche liefen jedoch in unterschiedlichen Umgebungen ab. Das Gigablock-Testnet verwendete 18 Nodes, während wir 24 Nodes für unsere Simulation verwendeten. Das Ergebnis einer Emulation sollte der Praxis mehr gleichen, als das einer Simulation. Die Zahl der Nodes war in beiden Fällen jedoch gering. Ich bin der Ansicht, dass Dash mehr Transaktionen pro Sekunde verarbeiten kann, da die Blockzeit geringer ist und dies Vorteile jenseits der einfachen Addition mit sich bringt. Unser Forschungsergebnis untermauert meine Ansicht noch weiter.

Es gibt bestimmte Hürden, um von der Simulation in die nächste Stufe vorzudringen. Eines der Probleme ist, dass aktuelle Dash-Clients nur eine bestimmte Zahl an Transaktionen pro Sekunde akzeptieren können. Dieses Problem kann gelöst werden.

Von Interesse ist auch, wie das Netzwerk auf eine größere Zahl an Nodes reagiert. Wir haben festgestellt, dass die Rate der verwaisten Blöcke bei 30% liegt, wenn wir an der wirtschaftlichen Grenze operieren. Dies ist zu hoch.

Ist es möglich Graphene mit Velocity zu kombinieren, um das Giftblock-Problem zu lösen?

Eine Idee, die weiterverfolgt werden sollte, ist die Kombination aus Graphene und Velocity. Velocity bringt gewissen Startschwierigkeiten mit sich, wenn ein Block noch nicht weit verteilt wurde. Ich würde gerne testen, wie sich Graphene verhält, wenn es auf Velocity ausweicht, wenn ein Dekodierungsfehler auftritt. Hierdurch könnte ein Graphene-Protokoll geschaffen werden, das resistent gegenüber Giftblock-Angriffen wäre.

Dieser Ansatz kann noch weitere Vorteile mit sich bringen. So wäre z.B. eine schnellere Synchronisationszeit möglich. Die Bitcoin-Blockchain könnte hierdurch in wenigen Stunden, statt in mehreren Tagen synchronisiert werden. Diese Möglichkeit zu betrachten, ist sehr spannend.

Hier gibt es das komplette Paper zu Velocity, falls sich jemand näher mit dem Thema beschäftigen möchte.