VaultxGPU: GPU-Accelerated Blockchain Consensus

Dieses Paper stellt VaultxGPU vor, einen GPU-beschleunigten Proof-of-Space-Plotter, der maßgeschneiderte CUDA- und SYCL-Kernel nutzt, um Sortier- und Matching-Stufen zu fusionieren, wodurch eine bis zu 59,2-fache Beschleunigung gegenüber Single-Threaded-CPU-Baselines erreicht wird und selbst hochparallele 384-Thread-CPU-Konfigurationen für das Blake3-Hashing übertrifft.

Das Wesentliche

Stellen Sie sich ein massives, digitales Kassenbuch vor (wie ein riesiges öffentliches Notizbuch), das jede Transaktion in einem Blockchain-Netzwerk aufzeichnet. Um dieses Notizbuch sicher und ehrlich zu halten, müssen alle zustimmen, was darin geschrieben steht. Dieser Abstimmungsprozess wird als „Konsens“ bezeichnet.

Lange Zeit war die beliebteste Art und Weise, dies zu tun, Proof-of-Work. Denken Sie an dies wie eine weltweite Lotterie, bei der Millionen von Menschen verzweifelt versuchen, ein mathematisches Rätsel zu lösen. Wer das Rätsel zuerst löst, gewinnt. Das Problem? Es verbraucht eine enorme Menge an Elektrizität, etwa so viel, wie ein kleines Land in einem Jahr verbraucht.

Um dies zu beheben, wurde eine neuere Methode namens Proof-of-Space erfunden. Anstatt Rätsel immer und immer wieder zu lösen, bereitet die Mine (Miner) eine riesige „Karte“ (genannt Plot) im Voraus vor und speichert sie auf ihren Festplatten. Wenn das Netzwerk eine Frage stellt, schaut der Miner einfach die Antwort auf seiner Karte nach. Dies verbraucht viel weniger Energie.

Das Problem:
Das Erstellen dieser riesigen Karten ist langsam. Es ist, als würde man versuchen, eine Bibliothek mit Büchern zu füllen, aber der Bibliothekar (der Computer-CPU) schreibt jedes einzelne Buch von Hand, Wort für Wort. Selbst wenn man einen sehr schnellen, teuren Bibliothekar hat, dauert es zu lange, um die Bibliothek bereit zu machen.

Die Lösung: VaultxGPU
Die Autoren dieser Arbeit haben ein neues Werkzeug namens VaultxGPU entwickelt. Anstatt einen langsamen Bibliothekar zu benutzen, haben sie ein Team aus superschnellen Robotern (der GPU, oder Grafikkarte) engagiert, um die schwere Arbeit zu erleden.

Hier ist die Erklärung, wie sie es gemacht haben, unter Verwendung einfacher Analogien:

1. Die Strategie „Ein Roboter pro Buch“

Bei der alten Methode versuchte die CPU, Bücher nacheinander oder in kleinen Gruppen zu schreiben. VaultxGPU weist jedem einzelnen Roboter eine Seite des Buches gleichzeitig zu.

• Die Analogie: Stellen Sie sich vor, Sie müssen 10.000 Umschläge mit Briefen füllen. Die CPU könnte eine Person haben, die es erledigt, oder vielleicht ein paar Leute, die sich die Arbeit teilen. VaultxGPU engagiert 10.000 Roboter, und jeder Roboter greift sich sofort einen Umschlag und füllt ihn, ohne jemals mit den anderen zu kommunizieren. Dies ist der Blake3-Hashing-Teil, der die eigentliche mathematische Arbeit darstellt.

2. Der „Verkehrsstau-freie“ Speicher

Normalerweise müssen Computer, wenn sie schwere Arbeit verrichten, ständig Daten zwischen dem Hauptspeicher und dem Prozessor hin- und herbewegen, wie ein Lieferwagen, der im Stau steht.

• Die Analogie: VaultxGPU hält alle notwendigen Daten direkt innerhalb des Arbeitsbereichs des Roboters (dem VRAM der GPU). Sie müssen die Daten nicht auf die Straße fahren und wieder zurückbringen. Sie halten alles in der „Küche“, sodass die Köche (Roboter) niemals ihren Platz verlassen müssen. Dies vermeidet die „Verkehrsstaus“, die andere Computer verlangsamen.

3. Die „fusionierte“ Küche

Der Prozess besteht aus zwei Hauptschritten: das Sortieren der Briefe und das Zusammenpassen der Paare. Normalerweise sortiert man die Briefe, legt sie in eine Box, fährt die Box in einen neuen Raum und passt sie dann zusammen.

• Die Analogie: VaultxGPU kombiniert diese Schritte. Sie sortieren die Briefe und passen sie im selben Raum zusammen, ohne die Box jemals bewegen zu müssen. Sie haben eine spezielle „fusionierte“ Küche gebaut, in der das Sortieren und das Zusammenpassen gleichzeitig stattfinden, was eine massive Menge an Zeit spart.

4. Verschiedene Sprachen sprechen

Das Paper erwähnt, dass sie dies für zwei verschiedene Arten von Roboter-Teams gebaut haben: NVIDIA (das eine Sprache namens CUDA verwendet) und AMD/Intel (das eine Sprache namens SYCL verwendet).

• Die Analogie: Es ist, als würde man ein Rezept schreiben, das perfekt funktioniert, egal ob Ihre Küche Gasherde (NVIDIA) oder Elektroherde (AMD/Intel) nutzt. Sie haben sichergestellt, dass die Kernanweisungen dieselben sind, aber sie haben die spezifischen Werkzeuge für jeden Herdentyp angepasst, damit jeder das gleiche köstliche Essen kochen kann.

Die Ergebnisse: Wie schnell ist es?

Das Team hat dies an einer Standard-Computeraufgabe getestet (Erstellung einer Karte für eine bestimmte Größe namens „K=31“).

• Der alte Weg (Einzel-CPU): Es dauerte 44 Minuten und 48 Sekunden (2.688 Sekunden).
• Der neue Weg (GPU):
  • Die AMD/Intel-Version erledigte es in 45,4 Sekunden.
  • Die NVIDIA-Version erledigte es in 53,8 Sekunden.
• Der Vergleich: Selbst wenn Sie einen Supercomputer mit 384 leistungsstarken CPU-Kernen verwendet hätten (der über 10.000 $ kostet), hätte er immer noch etwa 52 Sekunden gebraucht. Die GPU-Version war schneller oder fast genauso schnell, aber für einen viel niedrigeren Preis (etwa 5.000 $ für die Maschine).

Was ist immer noch schwierig?

Das Paper gibt zwei Dinge zu, die immer noch bremsen:

1. Der „Schreib“-Engpass: Obwohl die Roboter sehr schnell darin sind, die Karte zu erstellen, wird das Schreiben der fertigen Karte auf die Festplatte immer noch vom langsamen Menschen (der CPU) erledigt. Es ist, als hätten Sie ein Team von 10.000 Druckern, die ein Buch in einer Sekunde drucken können, aber Sie haben nur eine einzige Person, die das Buch ins Regal tragen kann. Dieser Schritt nimmt mehr als die Hälfte der gesamten Zeit in Anspruch.
2. Der „Sortier“-Fehler: Wenn die Karten größer werden, wird der Teil, in dem die Daten sortiert werden, langsamer, da sie eine einfache „Eins-nach-dem-anderen“-Sortierungsmethode verwenden. Es ist, als würde man versuchen, eine riesige Menge zu organisieren, indem man eine Person fragt, die nacheinander jeden Namen prüft; das funktioniert bei einer kleinen Gruppe gut, wird aber bei einer riesigen Menge chaotisch.

Fazsetzung

Das Paper kommt zu dem Schluss, dass die Verwendung von GPUs (Grafikkarten) der richtige Weg ist, um diese Blockchain-Karten zu erstellen. Es ist viel schneller und günstiger als die Verwendung von nur CPUs. Auch wenn es noch einige Geschwindigkeitsbarrieren gibt (wie die Schreibgeschwindigkeit der Festplatte), ist der „Roboterteam“-Ansatz eindeutig die Zukunft für die Skalierung dieser Technologie.

Technische Zusammenfassung

Technisches Resümee: VaultxGPU

Problemstellung

Blockchain-Konsensmechanismen, die auf Proof-of-Work (PoW) basieren, wie etwa Bitcoin, verursachen enorme Energiekosten (geschätzt ~150 TWh jährlich allein für Bitcoin). Proof-of-Space (PoSp) bietet eine energieeffiziente Alternative, indem es rechenintensive Arbeit durch Speicherplatz ersetzt. PoSp führt jedoch einen signifikanten Flaschenhals ein: Die einmalige Generierung großer „Plot-Dateien“ ist durch den CPU-Hashing-Durchsatz begrenzt. Während vorangegangene Arbeiten (VaultX) die CPU-basierte Plotting-Geschwindigkeit durch Multi-Threaded-Blake3-Hashing verbesserten, werden High-End-CPU-Konfigurationen weiterhin von Mittelklasse-GPU-Hardware überholt. Zudem begrenzen die sequentielle Natur des Blake3-Algorithmus und die Anforderungen an die Datenbewegung in den Sortier- und Matching-Phasen die Skalierbarkeit CPU-basierter Lösungen.

Methodik

Die Autoren präsentieren VaultxGPU, eine GPU-beschleunigte Erweiterung des VaultX-Plotters, die darauf ausgelegt ist, die gesamte Blake3-Hashing-Pipeline auf die GPU auszulagern. Das System wird mit zwei Backends implementiert: CUDA für NVIDIA-Hardware und SYCL (via Intel oneAPI DPC++) für AMD- und Intel-GPUs.

Zentrale architektonische Entscheidungen sind:

• Paralleles Hashing: Ein maßgeschneiderter Blake3-Kernel weist pro Nonce einen GPU-Thread über den gesamten $2^k$-Raum zu. Jeder Thread berechnet den Hash vollständig innerhalb seines Register-Files, wodurch Inter-Thread-Abhängigkeiten und Anforderungen an einen gemeinsamen Zustand eliminiert werden.
• Speichermanagement:
  • NVIDIA (CUDA): Nutzt __constant__-Speicher für den 256-Bit-Plot-Key, um ein Zero-Bandwidth-Broadcasting an die Warps zu ermöglichen. Atomare Bucket-Einfügevorgänge werden implizit durch die Runtime gehandhabt.
  • AMD/Intel (SYCL): Allokiert den Plot-Key via sycl::malloc_device und übergibt ihn als Pointer, was einen Global-Memory-Fetch-Overhead verursacht. Atomare Operationen werden explizit mittels sycl::atomic_ref mit definierten Speicherordnungen und Scopes deklariert.
• Fusionierter Sort- und Match-Prozess: Um die Datenbewegung zu minimieren, werden die Sortier- und Table-2-Generierungsphasen (Matching) in einem einzigen GPU-Kernel zusammengeführt. Dieser Kernel operiert vollständig innerhalb des Shared-Memorys (oder SYCL Local Memory) pro Bucket und vermeidet so Zwischenschritte über den Global Memory. Pro Bucket wird gleichzeitig ein Block gestartet, über alle $2^{24}$ Buckets hinweg.
• Datenpersistenz: Die gesamte Table-1-Datenstruktur (alle $2^k$ Nonce-Hash-Datensätze) verbleibt während des gesamten Prozesses im GPU-VRAM. Nur die finale Table-2-Ausgabe wird über PCIe an die Host-CPU übertragen, um sequenziell auf die Festplatte geschrieben zu werden.

Zentrale Beiträge

1. Maßgeschneiderter GPU-Blake3-Kernel: Eine Neugestaltung des Blake3-Keyed-Hashing-Algorithmus, um vollständig innerhalb des Registers eines einzelnen Threads zu laufen, was massives Parallelismus über den Nonce-Raum ermöglicht, ohne Synchronisation zwischen den Threads.
2. Dual-Backend-Implementierung: Eine portable Codebasis, die sowohl NVIDIA (CUDA) als auch AMD/Intel (SYCL) Hardware unterstützt, wobei ein gemeinsamer Hashing-Kernel verwendet wird, während das Speichermanagement und die atomaren Semantiken an das jeweilige Programmiermodell des Herstellers angepasst werden.
3. Kernel-Fusion: Die Integration der Sort- und Match-Phasen in einen einzigen Kernel, der ausschließlich im Shared Memory operiert und somit den Traffic im Global Memory zwischen diesen kritischen Pipeline-Stufen eliminiert.
4. Byte-Kompatibilität: Integration in den bestehenden VaultX-Konsensmechanismus, wodurch sichergestellt wird, dass GPU-generierte Plots direkt durch den CPU-Prover ohne Formatkonvertierung durchsuchbar sind.
5. Umfassende Evaluierung: Eine detaillierte Leistungsanalyse über K-Werte von 27 bis 31 im Vergleich zu Single-Threaded- und Multi-Threaded-CPU-Baselines (bis zu 384 Threads).

Ergebnisse

Die Evaluierung wurde auf Server-Hardware (NVIDIA Tesla V100s) und Consumer-Systemen (AMD Vega 20, Intel Arc A770) durchgeführt.

• Speedup: Bei K=31 erreichte die SYCL-GPU-Implementierung einen 59,2-fachen Speedup gegenüber einer Single-Threaded-CPU-Baseline und schloss einen Plot in 45,4 Sekunden ab, verglichen mit 2.688 Sekunden. Die CUDA-GPU erreichte einen 50,0-fachen Speedup (53,8 Sekunden).
• Vergleich zum Multi-threaded CPU: Beide GPU-Implementierungen übertrafen die beste 384-Thread-CPU-Konfiguration (52,2 Sekunden), was zeigt, dass die GPU-Beschleunigung die Grenzen der CPU-Parallelität selbst bei Hardware mit hoher Kernzahl überschreitet.
• Skalierung: Die SYCL-Implementierung zeigte eine nahezu ideale lineare Skalierung (Verhältnisse von ~2,0x), wenn sich die Problemgröße verdoppelte. Die CUDA-Implementierung zeigte initial eine sublineare Skalierung, trat aber bei K=31 in eine superlineare Region ein (Verhältnis 2,40x), was auf Ineffizienzen beim Kernel-Management bei größeren Bucket-Größen zurückzuführen ist.
• Engpässe:
  • Disk I/O: Die Schreibphase dominierte die Gesamtlaufzeit und machte 59–82 % der Zeit aus, da sie sequenziell auf der Host-CPU ausgeführt wird.
  • Sort/Match: Der Single-Threaded Insertion Sort pro Bucket erzeugte einen $O(n^2)$-Engpass, wodurch der Anteil der Sort/Table-2-Phase von 11 % der Pipeline-Zeit bei K=27 auf 34 % bei K=31 anstieg.

Bedeutung

Das Paper kommt zu dem Schluss, dass die GPU-Beschleunigung der richtige Weg ist, um Proof-of-Space-Plotting über die Fähigkeiten der CPU-Parallelität hinaus zu skalieren. Die Ergebnisse bestätigen, dass eine einzelne GPU eine hochpreisige, tausendpaarige CPU-Cluster-Konfiguration bei der Plot-Generierung übertreffen kann. Die Arbeit validiert, dass das Auslagern der Blake3-Pipeline und die Fusion nachfolgender Stufen zur Minimierung der Datenbewegung erhebliche Leistungssteigerungen liefert.

Die Autoren merken bescheiden an, dass die Hashing- und Sortierphasen nun GPU-gebunden sind, die Disk-I/O-Phase jedoch weiterhin ein sequenzieller CPU-Engpass bleibt. Sie identifizieren den Single-Threaded Insertion Sort und das Kernel-Management als Bereiche für zukünftige Optimierungen und schlagen vor, dass der Ersatz des Sortierverfahrens durch einen parallelen Algorithmus (z. B. Radix Sort) und das Überlappen von PCIe-Transfers mit der Berechnung die Performance weiter verbessern könnte. Die Studie legt damit das Fundament für die Skalierung von PoSp auf größere K-Werte und diverse Hardware-Ökosysteme.