Vitalik Buterin schlägt binären Zustandsbaum-Migration und RISC-V VM-Übergang für Protokolleffizienz vor

Ethereum-Mitbegründer Vitalik Buterin veröffentlichte einen detaillierten technischen Vorschlag, der zwei große Protokoll-Updates befürwortet: den Übergang vom aktuellen hexaren Merkle-Patricia-Baum zu einer binären Zustandsbaumstruktur und schließlich den Austausch der Ethereum Virtual Machine durch eine RISC-V-basierte Architektur.

Die Vorschläge, die in einem Beitrag vom März 2026 skizziert wurden, zielen darauf ab, Effizienzengpässe bei Beweisführungen zu beheben, den Datenbandbreitenbedarf zu reduzieren und die clientseitigen Verifikationsfähigkeiten zu verbessern. Buterin charakterisierte die Migration zum binären Baum als ein „Omnibus“-Upgrade, das zehn Jahre Erkenntnisse über das Design von Zustandsbäumen integriert, während er Änderungen an der VM als langfristiges Roadmap-Element positionierte, das Pre-Compiles weitgehend überflüssig machen und die Protokollarchitektur vereinfachen könnte.

Migration zum Binären Zustandsbaum für Effizienzsteigerung bei Beweisführungen vorgeschlagen

Buterin skizzierte EIP-7864, das derzeit entwickelt wird, welches den bestehenden hexaren keccak-Merkle-Patricia-Baum von Ethereum durch eine binäre Baumstruktur mit effizienteren Hash-Funktionen ersetzen soll. Die vorgeschlagene Änderung würde die Merkle-Zweig-Länge um den Faktor vier verringern, von 512*log(n)/4 auf 32*log(n) Bytes.

Diese Reduktion würde den Datenbandbreitenbedarf für clientseitige Verifikationswerkzeuge wie Helios und Systeme für private Informationsabfragen senken. Die Effizienz bei Beweisführungen würde allein durch kürzere Zweige um das Drei- bis Vierfache steigen, mit zusätzlichen Verbesserungen durch die Auswahl der Hash-Funktion. Potenzielle Hash-Funktionskandidaten sind blake3, das etwa dreimal effizienter als keccak ist, oder Poseidon-Varianten, die bei zusätzlicher Sicherheitsanalyse eine 100-fache Effizienzsteigerung bieten könnten.

Das Design des binären Baums integriert „Page“-Gruppierungen, die benachbarte Speicherplätze zu Seiten von 64 bis 256 Slots zusammenfassen, was 2 bis 8 Kilobyte Daten entspricht. Diese Struktur ermöglicht einen effizienten Speicherzugriff, ähnlich wie beim Laden und Bearbeiten von Code. Block-Header sowie die ersten etwa 1 bis 4 Kilobyte Code und Speicher würden in derselben Seite liegen, was potenziell mehr als 10.000 Gas pro Transaktion für dezentrale Anwendungen einsparen könnte, die häufig auf initiale Speicherplätze zugreifen.

Weitere Vorteile sind eine geringere Varianz in der Zugriffstiefe zwischen großen und kleinen Verträgen, eine einfachere Implementierung im Vergleich zu hexaren Strukturen sowie die Möglichkeit, Metadatenbits zu integrieren, die für zukünftige Zustandsablauf-Implementierungen benötigt werden.

Überlegung zum Übergang der Virtual Machine auf RISC-V-Architektur

Buterin präsentierte die Argumentation für den Austausch der Ethereum Virtual Machine durch eine RISC-V-basierte Architektur und beschrieb die EVM als an ihre Grenzen stoßend, um den Anforderungen des allgemeinen Zwecks von Ethereum gerecht zu werden. Der Vorschlag identifiziert mehrere Effizienz-Ziele für eine neue VM.

Reine Ausführungseffizienzsteigerungen könnten die meisten Pre-Compile-Anforderungen eliminieren. Die Effizienz der Beweisführer würde steigen, was aktuelle Einschränkungen behebt, bei denen Beweisführer für RISC-V und nicht für EVM geschrieben sind. Clientseitige Beweisführungsfähigkeiten würden es Nutzern ermöglichen, ZK-Beweise über das Verhalten von Konten unter bestimmten Datenbedingungen zu erstellen. Die Implementierung würde durch einen RISC-V-Interpreter, der nur wenige Hundert Zeilen Code benötigt, vereinfacht.

Ein dreiphasiger Einführungsfahrplan wurde skizziert. Phase eins würde die neue VM auf Pre-Compile-Funktionen beschränken, wobei etwa 80 Prozent der bestehenden Pre-Compiles und neue als NewVM-Code implementiert würden. Phase zwei würde die Nutzerbereitstellung von NewVM-Verträgen ermöglichen. Phase drei würde die EVM vollständig außer Dienst stellen und sie als Smart Contract in der neuen VM neu implementieren.

EVM-Nutzer würden diese Transition vollständig rückwärtskompatibel durchlaufen, wobei die Gas-Kosten die Hauptänderung darstellen, obwohl Buterin anmerkte, dass diese durch laufende Skalierungsarbeiten in den folgenden Jahren überlagert würden.

Kontext der Protokollentwicklung und Überlegungen für Entwickler

Buterin charakterisierte beide Vorschläge als Lösungen für die größten Engpässe bei der effizienten Beweisführung, die zusammen über 80 Prozent des Beweis-Overheads ausmachen. Die Änderungen werden als notwendig für verschiedene clientseitige Beweisführungsanwendungen beschrieben.

Die Migration zum binären Baum wurde als Integration von Erkenntnissen aus zehn Jahren Erfahrung im Design von Zustandsbäumen dargestellt. Der VM-Übergang wurde als spekulativer und derzeit nicht-konsensbasierter Ansatz positioniert, wobei Buterin erklärte, dass Ethereum mit nur EVM plus GPU-Verbesserungen funktionsfähig bleiben würde, aber eine bessere VM das Protokoll „schön und großartig“ machen könnte.

Beide Vorschläge sind auf Implementierungszeitpläne ausgerichtet, die mit der langfristigen Zustands-Roadmap von Ethereum übereinstimmen: Die Migration zum binären Baum erfolgt im EIP-Prozess, während der VM-Übergang als langfristige Initiative betrachtet wird, die nach Abschluss der Zustandsbaum-Änderungen umgesetzt werden soll.

FAQ: Vorschläge für Ethereum-Protokoll-Updates

Was ist der Unterschied zwischen dem aktuellen Ethereum-Zustandsbaum und dem vorgeschlagenen binären Baum?

Ethereum verwendet derzeit einen hexaren Merkle-Patricia-Baum mit keccak-Hashing. Der vorgeschlagene binäre Baum würde eine binäre Struktur mit effizienteren Hash-Funktionen nutzen und die Merkle-Zweig-Länge etwa um den Faktor vier verringern. Dies reduziert den Datenbandbreitenbedarf für clientseitige Verifikation und verbessert die Effizienz bei Beweisführungen. Das binäre Design gruppiert außerdem Speicherplätze in Seiten für effizienteren Zugriff.

Wie würde ein Übergang von EVM zu RISC-V bestehende Ethereum-Anwendungen beeinflussen?

Im Rahmen des vorgeschlagenen dreiphasigen Fahrplans würden bestehende EVM-Anwendungen während der gesamten Transition die volle Rückwärtskompatibilität behalten. Die EVM würde schließlich als Smart Contract in der neuen VM neu implementiert, sodass bestehende Verträge weiterhin funktionieren. Die Gas-Kosten würden sich ändern, diese Änderungen würden jedoch zusammen mit anderen Skalierungsverbesserungen umgesetzt.

Welche Effizienzsteigerungen könnte die neue VM bieten?

Eine RISC-V-basierte VM könnte eine reine Ausführungseffizienz bieten, die die meisten Pre-Compile-Anforderungen eliminiert, die Effizienz der Beweisführer im Vergleich zu aktuellen EVM-Implementierungen verbessern und clientseitige Beweisführungsfähigkeiten ermöglichen, um ZK-Beweise über das Verhalten von Konten zu erstellen. Die Implementierung wäre deutlich einfacher, mit einem Interpreter, der nur hunderte Zeilen Code benötigt, im Vergleich zur aktuellen Komplexität der EVM.