Vitalik Buterin strebt 80% Reduzierung der Nachweis-Kosten mit EIP-7864 an

Einführung

Vitalik Buterin, Mitbegründer von Ethereum (ETH), hat zwei technische Änderungen vorgeschlagen, die darauf abzielen, die Herausforderungen der Nachweiskosten im Blockchain-Netzwerk zu bewältigen. Diese Vorschläge sind im Ethereum Improvement Proposal (EIP) 7864 und verwandten Dokumenten skizziert.

Kurze technische Änderungen

Der kurzfristige Vorschlag, EIP-7864, sieht vor, den aktuellen hexary Keccak Merkle Patricia Tree von Ethereum durch eine binäre Baumstruktur zu ersetzen, die eine effizientere Hash-Funktion nutzt. Die bestehende hexary Struktur wurde für Prioritäten entworfen, die sich von der nachweislastigen Architektur unterscheiden, die die Ethereum-Entwickler derzeit verfolgen.

Die binäre Baumstruktur würde Merkle-Zweige erzeugen, die viermal kürzer sind als das aktuelle System, da binäre Operationen 32-mal log(n) im Vergleich zu hexary’s 512-mal log(n) geteilt durch 4 erfordern, gemäß den technischen Spezifikationen im Vorschlag. Diese Reduzierung würde die Kosten für die clientseitige Zweigverifizierung senken und die Datenbandbreitenanforderungen für Werkzeuge wie Helios und private Informationsabrufsysteme um denselben Faktor verringern.

Die Effizienzgewinne beim Nachweis würden über die Verbesserungen der Zweiglänge hinausgehen. Der Vorschlag weist darauf hin, dass kürzere Zweige eine Verbesserung von drei bis vier Mal liefern würden, unabhängig von der Optimierung der Hash-Funktion. Die Implementierung von Blake3 anstelle von Keccak könnte eine zusätzliche Verbesserung um das Dreifache bieten, während eine Poseidon-Variante potenziell eine Verbesserung um das Hundertfache liefern könnte, obwohl eine zusätzliche Sicherheitsanalyse erforderlich ist, bevor Poseidon implementiert wird.

Langfristige Vorschläge

Der langfristige Vorschlag sieht vor, die Ethereum Virtual Machine (EVM) durch eine effizientere virtuelle Maschine wie RISC-V zu ersetzen. Der Vorschlag argumentiert, dass die Architektur der EVM nicht für eine nachweislastige Blockchain optimiert ist und dass deren Ersetzung grundlegende Ineffizienzen angehen würde, anstatt sie durch angesammelte Precompiles und Umgehungen zu verwalten.

Buterins Vorschlag nennt vier Vorteile von RISC-V gegenüber der EVM:

1. Rohe Ausführungseffizienz: RISC-V übertrifft die EVM in einem Maße, das die Notwendigkeit vieler Precompiles beseitigen würde, da die zugrunde liegenden Berechnungen effizient innerhalb der VM selbst ausgeführt werden könnten.
2. Nachweiser-Effizienz: Zero-Knowledge-Prover sind derzeit in RISC-V geschrieben, was eine natürliche Ausrichtung mit der bestehenden Nachweis-Infrastruktur schafft.
3. Clientseitiger Nachweis: Eine RISC-V VM würde es Benutzern ermöglichen, lokal Zero-Knowledge-Beweise über Konto-Interaktionen mit spezifischen Daten zu generieren, was Datenschutz- und Verifizierungsanwendungen ermöglicht, die derzeit von der EVM ohne externe Werkzeuge nicht unterstützt werden.
4. Einfachheit: Ein RISC-V-Interpreter kann laut dem Vorschlag in mehreren hundert Zeilen Code implementiert werden.

Bereitstellungsfahrplan

Der im Vorschlag skizzierte Bereitstellungsfahrplan umfasst drei Phasen:

1. In der ersten Phase würde eine neue virtuelle Maschine, möglicherweise RISC-V, nur Precompiles behandeln, wobei aktuelle und neue Precompiles zu Code-Blobs in der neuen VM werden.
2. In der zweiten Phase könnten Benutzer Verträge direkt in der neuen VM bereitstellen.
3. In der dritten Phase würde die EVM außer Betrieb genommen und als Smart Contract in der neuen VM neu implementiert, wobei die Rückwärtskompatibilität für bestehende Verträge gewahrt bleibt. Die Hauptänderung wären Anpassungen der Gaskosten, die voraussichtlich von gleichzeitigen Skalierungsentwicklungen überschattet werden.

Schlussfolgerung

Buterin charakterisiert beide Änderungen als Ansätze zur Bewältigung derselben grundlegenden Herausforderung aus unterschiedlichen Blickwinkeln. Der Zustandsbaum und die VM zusammen machen mehr als 80 Prozent des Engpasses bei effizientem Nachweis aus. Die Behandlung einer der beiden Komponenten ohne die andere lässt das größere Problem teilweise ungelöst, während die Behandlung beider eine Protokollstruktur erzeugen würde, die mit der nachweislastigen Architektur, die Ethereum entwickelt hat, strukturell übereinstimmt.

Der Vorschlag erkennt an, dass der VM-Ersatz derzeit keinen Konsens innerhalb der Ethereum-Entwicklungsgemeinschaft darstellt und beschreibt ihn als eine Änderung, die deutlicher wird, sobald die Modifikationen des Zustandsbaums abgeschlossen sind. Die Änderungen werden als sequenziell präsentiert: Zuerst binäre Bäume, gefolgt von der VM-Ersetzung, sobald die Nachweis-Infrastruktur um die neue Zustandsstruktur gereift ist. Die EVM hat im Laufe der Jahre durch inkrementelle Ergänzungen an Komplexität zugenommen, und der Vorschlag besagt, dass die Erfüllung der Funktionalitätsanforderungen von Ethereum die Behandlung der VM erfordert, anstatt kontinuierlich Umgehungen zu implementieren.