Vitalik Buterin erforscht „Klebstoff und Coprozessor“ für die Datenverarbeitung

Ethereum Erfinder Vitalik Buterin beschäftigt sich mit einem neuen Konzept, wie moderne Computer in zwei Teile geteilt werden können: eine „Kleber“-Komponente und einen „Coprozessor“.

Die Idee hier ist einfach: Teilen Sie die Arbeit. Der Kleber erledigt die allgemeinen, nicht so intensiven Aufgaben, während der Coprozessor sich um die schweren, strukturierten Berechnungen kümmert. 

Vitalik schlüsselt es für uns auf und sagt, dass die meisten Berechnungen in Systemen wie der Ethereum Virtual Machine (EVM) bereits auf diese Weise aufgeteilt sind. Einige Teile des Prozesses erfordern eine hohe Effizienz, während andere flexibler, aber weniger effizient sind.

Nehmen wir zum Beispiel Ethereum . Bei einer aktuellen Transaktion, bei der Vitalik den IPFS-Hash seines Blogs auf dem Ethereum Name Service (ENS) aktualisierte, wurde der Gasverbrauch auf verschiedene Aufgaben verteilt. Die Transaktion verbrannte insgesamt 46.924 Gas. 

Die Aufteilung sieht folgendermaßen aus: 21.000 Gas für die Grundkosten, 1.556 für Anrufdaten und 24.368 für die EVM-Ausführung. Bestimmte Vorgänge wie SLOAD und SSTORE verbrauchten 6.400 bzw. 10.100 Gas. Der LOG-Betrieb verbrauchte 2.149 Gas, der Rest wurde durch verschiedene Prozesse aufgefressen.

Vitalik sagt, dass rund 85 % des Gases dieser Transaktion für einige schwere Vorgänge aufgewendet wurden – wie Speicherlese- und -schreibvorgänge, Protokollierung und Kryptografie.

Der Rest war das, was er „Geschäftslogik“ nennt, die einfacheren, übergeordneten Dinge, wie die Verarbeitung der Daten, die vorgeben, welcher Datensatz aktualisiert werden soll. 

Vitalik weist auch darauf hin, dass man dasselbe in in Python geschriebenen KI-Modellen sehen kann. Wenn beispielsweise ein Vorwärtsdurchlauf in einem Transformatormodell ausgeführt wird, wird die meiste Arbeit durch vektorisierte Operationen erledigt, wie etwa die Matrixmultiplikation. 

Diese Vorgänge werden normalerweise in optimiertem Code geschrieben, häufig CUDA, der auf GPUs ausgeführt wird. Die High-Level-Logik befindet sich jedoch in Python – einer allgemeinen, aber langsamen Sprache, die nur einen kleinen Teil des gesamten Rechenaufwands ausmacht.

Der Ethereum Entwickler glaubt auch, dass dieses Muster in der modernen programmierbaren Kryptographie wie SNARKs immer häufiger vorkommt.

Er weist auf Trends bei der STARK-Prüfung hin, bei der Teams Allzweckprüfer für minimale virtuelle Maschinen wie RISC-V entwickeln.

Jedes Programm, das geprüft werden muss, kann in RISC-V kompiliert werden, und der Prüfer prüft die RISC-V-Ausführung. Dieses Setup ist praktisch, bringt jedoch einen Mehraufwand mit sich. Programmierbare Kryptografie ist bereits teuer, und die zusätzlichen Kosten für die Ausführung von Code in einem RISC-V-Interpreter sind hoch.

Was machen Entwickler also? Sie umgehen das Problem. Sie dent die spezifischen, teuren Vorgänge, die den größten Teil der Berechnung in Anspruch nehmen – wie Hashes und Signaturen – und erstellen spezielle Module, um diese Vorgänge effizient zu beweisen. 

Anschließend kombinieren sie das allgemeine RISC-V-Prüfsystem mit diesen effizienten, spezialisierten Systemen und holen so das Beste aus beiden Welten heraus. Dieser Ansatz, so Vitalik, wird wahrscheinlich auch in anderen Bereichen der Kryptographie zu sehen sein, etwa bei der Mehrparteienberechnung (MPC) und der vollständig homomorphen Verschlüsselung (FHE).

Wo Kleber und Coprozessor ins Spiel kommen

Laut Vitalik erleben wir den Aufstieg einer „Klebstoff- und Coprozessor“-Architektur in der Datenverarbeitung. Der Kleber ist allgemein und langsam und für die Datenverarbeitung zwischen einem oder mehreren Coprozessoren verantwortlich, die spezialisiert und schnell sind. GPUs und ASICs sind perfekte Beispiele für Coprozessoren. 

Sie sind weniger allgemein als CPUs, aber für bestimmte Aufgaben viel effizienter. Der schwierige Teil besteht darin, die richtige Balance zwischen Allgemeingültigkeit und Effizienz zu finden.

In Ethereum muss die EVM nicht effizient sein, sie muss nur vertraut sein. Durch das Hinzufügen der richtigen Coprozessoren oder Vorkompilierungen können Sie eine ineffiziente VM fast genauso effektiv machen wie eine nativ effiziente. 

Aber was wäre, wenn das keine Rolle spielen würde? Was wäre, wenn wir akzeptieren würden, dass offene Chips langsamer sind, und zum Ausgleich eine Leim- und Coprozessor-Architektur verwenden würden? 

Die Idee besteht darin, einen Hauptchip zu entwerfen, der für Sicherheit und Open-Source-Design optimiert ist, und gleichzeitig proprietäre ASIC-Module für die aufwendigsten Berechnungen zu verwenden. 

Sensible Aufgaben könnten vom sicheren Hauptchip erledigt werden, während die schwere Arbeit, wie KI-Verarbeitung oder ZK-Prüfung, auf die ASIC-Module verlagert werden könnte.