Compass Investments

Kurz gesagt, von den beiden Konzepten ist dasjenige, das zeitlich näher liegt, EIP-7864, an dem @gballet und Kollegen arbeiten. Dabei wird der aktuelle Merkle-Patricia-Hexadezimalbaum von Ethereum durch einen Binärbaum mit einer leistungsfähigeren Hash-Funktion ersetzt.

Das aktuelle Hexadezimalbaum-Schema wurde entwickelt, um andere Prioritäten zu erfüllen, nicht für Ethereums zukünftigen Proof-of-Stake. Der Wechsel zu einem binären Baum würde uns viermal kürzere Merkle-Zweige bescheren, da die binäre Struktur eine logarithmische Abhängigkeit von der Größe von $32

times

log(n)$ hat, während der hexadezimale Baum eine $512

times

log(n) / 4$ hat. Durch die Verringerung der Verzweigungslängen wird die Client-Verifizierung viel billiger und die Bandbreitenanforderungen für Tools wie Helios und PIR werden reduziert.

Nun zu den Änderungen auf der Ausführungsebene. Ich habe bereits Kontoabstraktion, multidimensionales Gas, BAL und ZK-EVM erwähnt.

Hier beginnen die echten Effizienzgewinne bei den Nachweisen. Die 3-4-fache Verbesserung durch verkürzte Verzweigungen hängt nicht von der Änderung der Hash-Funktion ab, die mit blake3 anstelle von keccak einen zusätzlichen 3-fachen Gewinn bringen kann, oder sogar einen 100-fachen mit der Poseidon-Variante, obwohl Buterin davor warnt, dass vor der Implementierung von Poseidon noch Sicherheitsverbesserungen erforderlich sind.

Die binäre Baumstruktur führt auch das Konzept der seitenweisen Speicherorganisation ein, bei der zusammenhängende Zellen zu Seiten von 64-256 Slots zusammengefasst werden, was etwa 2-8 KB entspricht. Der Blockkopf und die ersten 1-4 KB von Code und Speicher teilen sich dieselbe Seite. Dies ermöglicht eine effiziente Stapelverarbeitung für Aufträge, die auf die ersten Speicherplätze zugreifen, anstatt für jeden Zugriff einzeln zu bezahlen. Buterin schätzt, dass dies bei dApps, die bereits Daten aus den ersten Speichern laden – was die Mehrheit der aktiven Verträge ist – über 10.000 Gas pro Transaktion einsparen könnte.

Binäre Bäume sind auch einfacher zu kodieren und zu validieren. Die vorhersehbarere Zugriffstiefe für große und kleine Verträge verringert die Schwankungen bei den Ausführungskosten, und die Struktur selbst lässt logischerweise Raum für die Implementierung der Metadaten, die für die Handhabung verzögerter Zustandsänderungen erforderlich sind. {

Das zweite Konzept ist längerfristig angelegt und muss, wie Buterin selbst zugibt, erst noch einen Konsens finden.

Die Idee ist, dass die EVM-Architektur nicht die beste Grundlage für eine beweiszentrierte Blockchain ist. Der Ersatz durch eine geeignetere VM, wie RISC-V, würde das Problem grundlegend lösen, anstatt es mit einer Ansammlung von Vorkompilierungen und Umgehungen zu verschleiern. Die Argumente von

Buterin basieren auf vier Vorteilen von RISC-V gegenüber EVM. Der erste ist die Ausführungsleistung: RISC-V ist dem EVM so weit überlegen, dass viele Vorkompilierungen überflüssig werden, da die grundlegenden Berechnungen, für die sie erforderlich sind, von der virtuellen Maschine selbst effizient durchgeführt werden können. Der zweite Punkt ist die Effizienz von Beweisen: Heute werden ZK-Beweise auf RISC-V erstellt, was bedeutet, dass RISC-V-VMs nativ mit der bestehenden Beweisinfrastruktur kompatibel sind.

Drittens – clientseitige Verifizierung: RISC-V VMs ermöglichen es Benutzern, lokal ZK-Beweise dafür zu erstellen, was passiert, wenn auf ihr Konto mit einem bestimmten Datensatz zugegriffen wird. Dies eröffnet Möglichkeiten für Datenschutz- und Verifizierungsszenarien, die für EVMs ohne externe Add-ons unerreichbar sind. Und viertens die Einfachheit: Der RISC-V-Interpreter besteht nur aus ein paar hundert Zeilen Code, was genau die richtige Menge an Code für eine Blockchain-VM ist.