Vitalik schlägt umfassende Überarbeitung der Deep Execution Layer vor

Vitalik Buterin schlägt bedeutende Änderungen an der Ethereum-Ausführungsebene vor, darunter binäre Zustandsbäume und einen möglichen Wechsel vom EVM zu RISC-V.

Ethereum-Mitbegründer Vitalik Buterin hat im Rahmen seiner Skalierungsroadmap eine umfassende Überarbeitung der Ausführungsebene des Netzwerks vorgeschlagen.

Der Plan zielt auf Engpässe bei Beweisführung und Ausführung ab und konzentriert sich auf strukturelle Aktualisierungen. Zu den wichtigsten Vorschlägen gehören der Wechsel zu einem binären Zustandsbaum und die potenzielle Ablösung des EVM durch die RISC-V-Architektur.

Vorschlag für Binären Zustandsbaum

Die Roadmap umfasst EIP 7864, das den aktuellen hexaren Merkle-Patricia-Baum ersetzt. Das neue Design verwendet einen binären Baum und eine effizientere Hash-Funktion.

Entwickler wie Guillaume Ballet haben an dem Vorschlag gearbeitet. Die binäre Struktur verkleinert die Merkle-Zweiggrößen.

Kürzere Zweige verringern den Bandbreitenbedarf für die Verifikation. Dies kann die Kosten für Light Clients und private Informationsabrufsysteme senken.

Jetzt, Änderungen an der Ausführungsebene. Ich habe bereits über Account-Abstract, multidimensionale Gas, BALs und ZK-EVMs gesprochen.

Ich habe hier auch über ein kurzfristiges EVM-Upgrade gesprochen, das meiner Meinung nach sehr wertvoll sein wird: eine vektorisierte Mathematik-Precompile (im Wesentlichen, 32-Bit-Operationen oder potenziell…

— vitalik.eth (@VitalikButerin) 1. März 2026

Buterin erklärte, dass Zweige um das Vierfache kürzer werden könnten. Das würde die clientseitige Verifikation praktikabler machen und die Effizienz von Zero-Knowledge-Beweisen verbessern.

Der Vorschlag berücksichtigt auch einen Wechsel der Hash-Funktion. Optionen sind Blake3 oder eine Poseidon-Variante.

Blake3 könnte moderate Geschwindigkeitsgewinne bringen, während Poseidon die Leistung der Beweisführer weiter verbessern könnte.

Der Vorschlag gruppiert Speicherplätze in Seiten von 64 bis 256 Slots, was die Gas-Kosten für Verträge, die angrenzenden Speicher nutzen, senken könnte.

Viele Anwendungen verwenden häufig frühe Speicherplätze, und diese Struktur könnte die Ausführungskosten verringern.

Der binäre Baum reduziert auch die Variabilität der Zugriffstiefe, vereinfacht das Modell und unterstützt zukünftige Metadaten für Ablaufzeiten des Zustands.

Vorgeschlagener Wechsel der virtuellen Maschine

Der zweite Teil des Vorschlags betrifft die Ethereum Virtual Machine. Buterin diskutierte den Austausch des EVM durch eine auf RISC V basierende virtuelle Maschine.

Diese Änderung wird als langfristig und derzeit nicht konsensfähig beschrieben. Er argumentierte, dass die Protokollkomplexität im Laufe der Zeit zugenommen habe.

Einige Entwickler meiden die Nutzung des EVM aufgrund wahrgenommener Einschränkungen. Er sagte, eine neue VM könnte die Einfachheit und Allgemeingültigkeit wiederherstellen.

RISC V ist eine offene Standard-Instruction-Set-Architektur. Prover werden heute häufig in RISC V geschrieben. Die Angleichung des Protokoll-VMs an die Prover-Umgebungen könnte die Effizienz verbessern.

Buterin sagte, dass ein RISC V-Interpreter kompakt sein könne. Er beschrieb ihn als nur wenige Hundert Zeilen Code. So sollte sich eine Blockchain-VM anfühlen.

Der Vorschlag zielt auch darauf ab, die Abhängigkeit von Precompiles zu verringern. Eine effizientere VM könnte viele Precompiles überflüssig machen. Das würde die Protokollregeln vereinfachen und Sonderfälle reduzieren.

Client-seitiges Beweisen ist ein weiterer Fokus. Nutzer könnten Beweise für Vertragsaufrufe lokal generieren. Das passt zu den breiteren Plänen zur Integration von Zero-Knowledge.

Verwandte Lektüre: Vitalik skizziert Ethereum’s schnellen Plan zur Reduktion der L1-Slots

Phasenweiser Einführungsfahrplan

Der Vorschlag skizziert einen schrittweisen Übergangsplan. Der erste Schritt würde nur die neue VM für Precompiles erlauben.

Viele bestehende Precompiles könnten in den neuen VM-Code integriert werden. Die zweite Phase würde es Nutzern ermöglichen, Verträge direkt in der neuen VM zu deployen.

Dies würde parallel zum bestehenden EVM laufen. Entwickler könnten ihre bevorzugte Umgebung wählen.

Die letzte Phase würde den EVM außer Betrieb nehmen. Der EVM selbst könnte als Smart Contract innerhalb der neuen VM laufen.

Dieser Ansatz soll die Rückwärtskompatibilität wahren. Die Gas-Kosten könnten sich während des Übergangs ändern.

Der Fahrplan deutet jedoch an, dass breitere Skalierungsmaßnahmen diese Effekte ausgleichen könnten. Der Fokus bleibt auf Effizienz und sauberem Design.

Buterin sagte, Ethereum könne auch nur mit inkrementellen Upgrades funktionieren. Er präsentierte die Überarbeitung jedoch als eine strukturelle Verbesserung.

Der Vorschlag sieht die Ausführungsebene als zentral für zukünftige Skalierbarkeit. Die Roadmap verbindet die Reform des Zustandsbaums mit dem VM-Austausch.

Beide Maßnahmen zielen auf Effizienz bei Beweisführung und clientseitiger Nutzung ab. Der Vorschlag befindet sich nun in einer breiteren Diskussion innerhalb der Ethereum-Community.