Vitalik Buterin erforscht „Klebstoff und Koprozessor“ für das Rechnen

Ethereum -Schöpfer Vitalik Buterin beschäftigt sich mit einem neuen Konzept, wie moderne Computertechnik in zwei Teile aufgeteilt werden kann: eine „Klebstoffkomponente“ und einen „Koprozessor“

Die Idee ist einfach: Arbeit aufteilen. Der „Klebstoff“ erledigt die allgemeinen, weniger rechenintensiven Aufgaben, während der „Koprozessor“ die aufwändigen, strukturierten Berechnungen durchführt. 

Vitalik erklärt es uns genauer und sagt, dass die meisten Berechnungen in Systemen wie der Ethereum Virtual Machine (EVM) bereits so aufgeteilt sind. Einige Teile des Prozesses erfordern hohe Effizienz, während andere flexibler, aber weniger effizient sind.

Nehmen wir beispielsweise Ethereum. Bei einer kürzlich durchgeführten Transaktion, bei der Vitalik den IPFS-Hash seines Blogs im Ethereum Name Service (ENS) aktualisierte, verteilte sich der Gasverbrauch auf verschiedene Aufgaben. Insgesamt wurden für die Transaktion 46.924 Gaseinheiten verbraucht. 

Die Aufschlüsselung sieht wie folgt aus: 21.000 Gas für die Grundkosten, 1.556 für die Anrufdaten und 24.368 für die EVM-Ausführung. Spezielle Operationen wie SLOAD und SSTORE verbrauchten 6.400 bzw. 10.100 Gas. LOG-Operationen benötigten 2.149 Gas, der Rest wurde von verschiedenen Prozessen verbraucht.

Vitalik sagt, dass etwa 85 % des Gasverbrauchs bei dieser Transaktion für einige wenige rechenintensive Operationen verwendet wurden – wie etwa Lese- und Schreibvorgänge im Speicher, Protokollierung und Kryptographie.

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 außerdem darauf hin, dass man dasselbe bei in Python geschriebenen KI-Modellen beobachten kann. Beispielsweise wird beim Durchlauf eines Transformer-Modells der Großteil der Arbeit durch vektorisierte Operationen wie die Matrixmultiplikation erledigt. 

Diese Operationen werden üblicherweise in optimiertem Code geschrieben, oft in CUDA, das auf GPUs läuft. Die übergeordnete Logik ist jedoch in Python implementiert – einer allgemeinen, aber langsamen Sprache, die nur einen kleinen Teil der gesamten Rechenkosten ausmacht.

Der Ethereum Entwickler ist außerdem der Ansicht, dass dieses Muster in der modernen programmierbaren Kryptographie, wie beispielsweise SNARKs, immer häufiger vorkommt.

Er verweist auf Trends im STARK-Proving, wo Teams universelle Prover für minimale virtuelle Maschinen wie RISC-V entwickeln.

Jedes Programm, dessen Gültigkeit bewiesen werden muss, kann in RISC-V kompiliert werden, und der Beweiser prüft die Ausführung in RISC-V. Diese Vorgehensweise ist zwar praktisch, aber mit zusätzlichem Aufwand verbunden. Programmierbare Kryptografie ist ohnehin schon teuer, und die zusätzlichen Kosten für die Ausführung des Codes in einem RISC-V-Interpreter sind erheblich.

Was machen die Entwickler also? Sie umgehen das Problem. Siedentdie spezifischen, aufwändigen Operationen, die den größten Teil der Rechenleistung beanspruchen – wie Hashes und Signaturen – und erstellen spezialisierte Module, um diese Operationen effizient zu beweisen. 

Anschließend kombinieren sie das allgemeine RISC-V-Beweissystem mit diesen effizienten, spezialisierten Systemen und vereinen so die Vorteile beider Ansätze. Vitalik merkt an, dass dieser Ansatz wahrscheinlich auch in anderen Bereichen der Kryptographie, wie der Mehrparteienberechnung (MPC) und der vollständig homomorphen Verschlüsselung (FHE), Anwendung finden wird.

Wo Klebstoff und Coprozessor ins Spiel kommen

Laut Vitalik erleben wir derzeit den Aufstieg einer „Klebstoff- und Koprozessor“-Architektur im Computerbereich. Der Klebstoff ist allgemein und langsam und für die Datenverarbeitung zwischen einem oder mehreren spezialisierten und schnellen Koprozessoren zuständig. GPUs und ASICs sind perfekte Beispiele für Koprozessoren. 

Sie sind weniger vielseitig als CPUs, aber für bestimmte Aufgaben deutlich effizienter. Die Schwierigkeit besteht darin, das richtige Gleichgewicht zwischen Vielseitigkeit und Effizienz zu finden.

In Ethereummuss die EVM nicht effizient sein, sondern lediglich vertraut. Durch Hinzufügen geeigneter Koprozessoren oder Präkompilierungen lässt sich eine ineffiziente VM fast so effektiv wie eine von Natur aus effiziente machen. 

Was aber, wenn das keine Rolle spielte? Was, wenn wir akzeptierten, dass offene Chips langsamer wären und stattdessen auf Glue- und Coprozessorarchitektur zurückgriffen, um dies auszugleichen? 

Die Idee ist, dass man einen Hauptchip entwerfen könnte, der auf Sicherheit und Open-Source-Design optimiert ist, während für die rechenintensivsten Aufgaben proprietäre ASIC-Module verwendet werden. 

Sensible Aufgaben könnten vom sicheren Hauptchip übernommen werden, während rechenintensive Aufgaben wie die KI-Verarbeitung oder der ZK-Beweis auf die ASIC-Module ausgelagert werden könnten.