Vitalik Buterin erforscht „Kleber und Coprozessor“ für die Berechnung

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

Die Idee hier ist einfach: Die Arbeit aufteilen. Der Kleber erledigt die allgemeinen, nicht so intensiven Aufgaben, während der Coprozessor die schweren, strukturierten Berechnungen übernimmt. 

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

Nehmen wir Ethereum zum Beispiel. Bei einer kürzlichen Transaktion, bei der Vitalik den IPFS-Hash seines Blogs im Ethereum Name Service (ENS) aktualisierte, verteilte sich der Gasverbrauch auf verschiedene Aufgaben. Die Transaktion verbrannte insgesamt 46.924 Gas. 

Die Aufteilung sieht wie folgt aus: 21.000 Gas für die Grundgebühr, 1.556 für Calldata und 24.368 für die EVM-Ausführung. Spezifische Operationen wie SLOAD und SSTORE verbrauchten jeweils 6.400 bzw. 10.100 Gas. LOG-Operationen kosteten 2.149 Gas, und der Rest wurde von verschiedenen Prozessen verschlungen.

Vitalik sagt, dass rund 85 % des Gases in dieser Transaktion auf wenige schwere Operationen entfielen – wie Speicherlese- und -schreibvorgänge, Protokollierung und Kryptographie.

Der Rest war das, was er „Business Logic“ nennt, die einfacheren, höherstufigen Dinge, wie die Verarbeitung der Daten, die bestimmen, welchen Datensatz zu aktualisieren ist. 

Vitalik weist auch darauf hin, dass man dasselbe Muster in in Python geschriebenen KI-Modellen sehen kann. Wenn beispielsweise ein Forward-Pass in einem Transformer-Modell ausgeführt wird, wird die meiste Arbeit von vektorisierten Operationen wie der Matrixmultiplikation erledigt. 

Diese Operationen werden normalerweise in optimiertem Code geschrieben, oft CUDA, das auf GPUs läuft. Die hochstufige Logik befindet sich jedoch in Python – einer allgemeinen, aber langsamen Sprache, die nur einen kleinen Teil der gesamten Rechenkosten beansprucht.

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

Er verweist auf Trends im STARK-Beweis, bei dem Teams allgemeine Beweiser für minimale virtuelle Maschinen wie RISC-V entwickeln.

Jedes Programm, das einen Beweis benötigt, kann in RISC-V kompiliert werden, und der Beweiser beweist die RISC-V-Ausführung. Diese Einrichtung ist bequem, bringt aber Overhead mit sich. Programmierbare Kryptographie ist bereits teuer, und das Hinzufügen der Kosten für die Ausführung von Code innerhalb eines RISC-V-Interpreters ist viel.

Was tun Entwickler also? Sie umgehen das Problem. Sie identifizieren die spezifischen, teuren Operationen, die den Großteil der Berechnung ausmachen – wie Hashes und Signaturen – und erstellen spezialisierte Module, um diese Operationen effizient zu beweisen. 

Dann kombinieren sie das allgemeine RISC-V-Beweissystem mit diesen effizienten, spezialisierten Systemen und erhalten das Beste aus beiden Welten. Dieser Ansatz, so Vitalik, wird wahrscheinlich in anderen Bereichen der Kryptographie zu sehen sein, wie Multi-Party-Computation (MPC) und Fully Homomorphic Encryption (FHE).

Wo Kleber und Coprozessor ins Spiel kommen

Laut Vitalik erleben wir den Aufstieg einer „Kleber- und Coprozessor“-Architektur in der Informatik. Der Kleber ist allgemein und langsam und verantwortlich für die Handhabung der Daten zwischen einem oder mehreren Coprozessoren, 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 weitaus effizienter. Der knifflige Teil besteht darin, das richtige Gleichgewicht zwischen Allgemeinheit 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 Precompiles kann eine ineffiziente VM fast so effektiv sein wie eine nativ effiziente. 

Aber was, wenn das keine Rolle spielt? Was, wenn wir akzeptieren, dass offene Chips langsamer sind und die Kleber- und Coprozessor-Architektur verwenden, um dies auszugleichen? 

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

Sensible Aufgaben könnten vom sicheren Hauptchip übernommen werden, während die Schwerstarbeit, wie KI-Verarbeitung oder ZK-Beweise, an die ASIC-Module ausgelagert werden könnte.