Autor: Grey Lobster, Deep Tide TechFlow
Ethereum-Entwickler haben eine unausgesprochene Gewohnheit: Wenn es vermieden werden kann, EVM zu verwenden, dann wird die EVM vermieden.
In den letzten Jahren war die erste Reaktion der Entwickler bei neuen kryptografischen Operationen auf der Chain nicht, diese in der EVM zu implementieren, sondern einen “Precompiled Contract” zu beantragen – eine Abkürzung, um die virtuelle Maschine zu umgehen und direkt auf Protokollebene hartcodiert zu werden.
Am 1. März veröffentlichte Vitalik Buterin einen langen Beitrag auf X, in dem er diese Barriere endgültig durchbrach. Seine Kernaussage war: Die ganze Bedeutung von Ethereum liegt in seiner Vielseitigkeit. Wenn die EVM nicht ausreicht, sollten wir das Problem direkt angehen und eine bessere virtuelle Maschine bauen.
Er präsentierte zwei konkrete Ansätze.
Erster Ansatz: Austausch der “Datenstruktur”
Die erste Änderung betrifft den Ethereum-Statusbaum. Man kann ihn verstehen als Ethereum’s “Ledger-Index-System”, das bei jeder Kontostandsabfrage oder Transaktionsüberprüfung entlang des Baumes durchsucht wird.
Das Problem ist, dass der Baum derzeit zu “dick” ist. Ethereum verwendet eine Struktur namens “Hexa-Branch Keccak Merkle Patricia Tree” (ein langes Wort, das wie ein Zauberspruch klingt). Vitalik schlägt vor, EIP-7864, diesen Baum in einen einfacheren Binärbaum umzuwandeln.
Ein Beispiel: Früher musste man bei einer Datenabfrage an einer Kreuzung mit sechs Wegen immer wieder Richtungen wählen. Jetzt nur noch links oder rechts. Das Ergebnis? Die Länge der Merkle-Branches wird auf ein Viertel reduziert. Für leichte Clients bedeutet das eine deutlich geringere Bandbreite bei der Datenüberprüfung.
Doch Vitalik ist nicht zufrieden damit, nur die Form des Baumes zu ändern. Er will auch die “Schrift auf den Blättern” austauschen, also die Hash-Funktion. Es gibt zwei Kandidaten: Blake3 und Poseidon.
- Blake3 bietet stabile Geschwindigkeitssteigerungen;
- Poseidon ist radikaler und könnte die Beweis-Effizienz um mehrere Dekaden verbessern, aber die Sicherheit muss noch umfassend geprüft werden.
Interessanterweise ersetzt dieser Ansatz den seit Jahren diskutierten Verkle Trees. Diese waren für den Hard Fork 2026 favorisiert, verloren aber ab Mitte 2024 an Bedeutung, da die zugrunde liegende elliptische Kurven-Kryptografie durch Quantencomputing bedroht ist. Der Binärbaum-Ansatz gewinnt dadurch an Zugkraft.
Zweiter Ansatz: Austausch der “Virtuellen Maschine” – EVM wird zu einem Smart Contract
Der zweite Ansatz ist noch mutiger und kontroverser: Langfristig soll die EVM durch eine RISC-V-Architektur ersetzt werden.
RISC-V ist eine offene Befehlssatzarchitektur, die ursprünglich nichts mit Blockchain zu tun hatte. Mittlerweile wird sie jedoch in fast allen ZK-Proof-Systemen verwendet. Vitaliks Argumentation ist simpel: Da die Beweis-Generatoren bereits RISC-V verwenden, macht es keinen Sinn, eine andere virtuelle Maschine zu haben und dann noch eine Übersetzungsschicht einzubauen. Diese Übersetzung würde nur die Effizienz verringern.
Ein RISC-V-Interpreter benötigt nur wenige Hundert Zeilen Code. Vitalik meint, so sollte eine Blockchain-VM aussehen.
Er plant eine dreistufige Umsetzung: Zuerst soll die neue VM die Precompiled Contracts ausführen, um 80 % der bestehenden Precompiles mit der neuen VM neu zu implementieren; dann sollen Entwickler direkt Verträge auf der neuen VM deployen können, parallel zur EVM; schließlich wird die EVM abgeschafft, aber nicht vollständig entfernt – sie wird in einen Smart Contract umgewandelt, der auf der neuen VM läuft und volle Rückwärtskompatibilität bietet.
Alte Nutzer müssen nicht umsteigen. Der Motor wird nur still und heimlich ausgetauscht, das Lenkrad bleibt das gleiche.
Wie wichtig sind diese beiden Änderungen? Vitalik nennt eine Zahl: Statusbaum und virtuelle Maschine machen zusammen über 80 % der Engpässe bei Ethereum’s Beweis-Generierung aus. Ohne diese Änderungen stagniert die Skalierung im ZK-Zeitalter.
Arbitrum widerspricht: Man kann nicht den Lagerraum mit einem Gabelstapler ausstatten und dann den Kurier auch mit Gabelstaplern schicken
Doch nicht jeder stimmt dem zu.
Im November letzten Jahres veröffentlichte das Kernentwicklungsteam von Arbitrum, Offchain Labs, eine detaillierte technische Gegenargumentation. Vier Forscher betonten: RISC-V ist zwar gut für ZK-Beweise geeignet, aber nicht für die “Lieferformate” von Verträgen.
Sie unterscheiden klar zwischen “dISA” (Delivery Instruction Set) und “pISA” (Proof Instruction Set) – sie müssen nicht identisch sein. Ein Lager, das mit Gabelstaplern arbeitet, ist effizient, aber das bedeutet nicht, dass Kurierfahrer auch Gabelstapler brauchen.
Offchain Labs schlägt vor, WebAssembly (WASM) als Vertragsformat zu verwenden, weil: WASM auf Standardhardware effizient läuft, die meisten Ethereum-Knoten keine RISC-V-Chips haben, und eine Umstellung auf WASM eine bewährte Typensicherheitsprüfung sowie eine robuste Toolchain-Ökologie bietet.
Wichtig ist auch, dass sie nicht nur reden: Offchain Labs hat bereits einen Prototyp auf Arbitrum laufen, bei dem WASM als Vertragsformat genutzt wird, das dann in RISC-V für ZK-Beweise übersetzt wird. Beide Schichten arbeiten unabhängig, ohne sich zu stören.
Sie warnen auch vor einem Risiko: Die ZK-Technologie entwickelt sich rasant. Kürzlich wurde RISC-V von 32 auf 64 Bit umgestellt. Wenn man jetzt RISC-V fest in Ethereum L1 integriert, besteht die Gefahr, dass in zwei Jahren eine bessere Beweisarchitektur auftaucht. Ein Einsatz auf einer sich schnell bewegenden Zielscheibe ist nicht typisch für Ethereum.
Ein größerer Kontext: Layer-2s beginnen, “abzuhauen”
Um diese Vorschläge zu verstehen, braucht es einen größeren Blickwinkel.
Vor einem Monat stellte Vitalik öffentlich in Frage, ob Ethereum noch einen “spezifischen Layer-2-Roadmap” braucht, was eine kollektive Reaktion der L2-Community auslöste. Ben Fisch, CEO von Espresso Systems, sagte gegenüber CoinDesk: Vitaliks Punkt ist, dass L2 ursprünglich zur Skalierung von Ethereum gedacht war. Jetzt, da Ethereum selbst schneller wird, muss sich die Rolle der L2 ändern.
Interessanterweise reagieren die L2s nicht panisch, sondern beginnen, sich “von Ethereum zu lösen”. Jing Wang, Mitgründer von OP Labs, vergleicht L2 mit einer eigenständigen Website, während Ethereum die zugrunde liegende offene Abrechnungsschnittstelle ist. Marc Boiron, CEO von Polygon, sagt es noch direkter: Das eigentliche Problem ist nicht die Skalierung, sondern die Schaffung eines einzigartigen Blockraums für reale Anwendungsfälle wie Zahlungen.
Kurz gesagt: Vitaliks große Änderungen auf der Ausführungsebene sind ein technischer Kommentar zu einem größeren Trend: Ethereum gewinnt die Kontrolle über seine Kernfähigkeiten zurück, während die L2s sich entweder gezwungen sehen oder endlich einen Grund finden, eigenständig zu existieren.
Wird das funktionieren?
Vitalik gibt selbst zu, dass der Austausch der virtuellen Maschine derzeit noch keinen breiten Konsens in der Entwicklergemeinschaft hat. Die Statusbaum-Reform ist ausgereifter, mit konkreten Entwürfen und Teams. Aber der Austausch der EVM durch RISC-V? Das ist noch im “Roadmap”-Stadium, weit entfernt vom Code.
Doch Vitalik äußerte letzte Woche eine beeindruckende Einschätzung: Ethereum hat bereits einmal den Triebwerk bei The Merge gewechselt, und kann in den nächsten Jahren noch etwa vier weitere Änderungen vornehmen – Statusbaum, vereinfachte Konsensmechanismen, ZK-EVM-Verifikation, virtuelle Maschine.
Das Ethereum-Upgrade Glamsterdam ist für das erste Halbjahr 2026 geplant, Hegota folgt kurz darauf. Die genauen Inhalte der beiden Hard Forks sind noch nicht final, aber die Statusbaum-Reform und die Optimierung der Ausführungsschicht sind die klaren Hauptlinien.
Die Geschichte von Ethereum ist nie eine Frage des “Ob”. Vom PoW- zum PoS-Mechanismus, vom L1-Ansatz zum Rollup-Zentrum – es hat immer wieder bewiesen, dass es die Fähigkeit und den Mut hat, in großer Höhe die Triebwerke zu wechseln.
Dieses Mal geht es um tiefere Schichten – nicht um neue Funktionen, sondern um das Aufbrechen und Neu-Gießen alter Fundamente. Ob es eine tiefgründige, strategische Erneuerung ist oder ein endloser, immer komplexer werdender Umbau – die Antwort wird wohl erst 2027 klar sein.
Eines ist jedoch sicher: Ethereum plant nicht, im ZK-Zeitalter eine “reparierte alte Maschine” zu sein. Wie die Patches aussehen und welcher Motor ersetzt wird, ist vielleicht sogar wichtiger als die endgültige Lösung.
