EIP-8288: Post-Quanten-Beweise mit EVM, RISC-V oder eigener ISA?

Victoria Shinder10 October 2026, 09:472 Min. Lesezeit

Ein Beitrag auf Ethereum Research vom 8. Oktober behandelt eine Designfrage hinter EIP-8288: Wenn Ethereum Transaktionen von Post-Quanten-Beweisen abhängig machen lässt, die außerhalb der EVM geprüft werden, was genau soll ein Beweis belegen — und in welchem Befehlssatz?

Die Ausgangslage. EIP-8288 erlaubt Transaktionen, von Post-Quanten-Signaturen (leanSPHINCS) und STARK-Beweisen (leanSTARK) abzuhängen, deklariert in einem Abhängigkeits-Frame einer EIP-8141-Frame-Transaktion. Knoten prüfen sie vor dem Weiterleiten, und jeder Block trägt einen einzigen rekursiven STARK, der alle Abhängigkeiten belegt. Anlass sind Privacy-Pools: Heute prüft ein Pool einen Groth16-Beweis im Vertrag über die BN254-Pairing-Precompile, und ein Quantencomputer, der BN254 bricht, könnte solche Beweise fälschen. Unter EIP-8288 prüft der Pool nur, dass die Transaktion von einem Beweis für sein eigenes Programm mit den erwarteten öffentlichen Eingaben abhängt.

Das Problem. EIP-8288 identifiziert die Berechnung eines Beweises derzeit über einen Hash des Verifikationsschlüssels — ein Platzhalter. Dieser Schlüssel würde sich mit jedem Update von leanVM ändern, der zkVM, die leanSTARK-Beweise erzeugt, und jeden nicht aktualisierbaren Pool brechen. Der Beitrag schlägt stattdessen vor, dass Beweise zeigen, dass ein Programm korrekt lief, identifiziert als program_id = hash(ISA-Version, Programmbytes).

Drei Kandidaten laut Vergleich der Autoren:

• EVM — könnte zuerst kommen, weil Ethereum sie schon pflegt, läuft aber über einen Interpreter: etwa 2× die Zyklen von RISC-V, wenn eine Precompile die Hauptarbeit macht, 78–163×, wenn EVM-Code sie macht (ihr Privacy-Pool-Benchmark mit BLAKE2s).
• RISC-V (RV64IM nach den Ethereum zkVM Standards) — native Beweisgeschwindigkeit und das größte zkVM-Werkzeug-Ökosystem, aber Ethereum muss erst festlegen, was der Standard offenlässt, etwa die Speicheraufteilung.
• Eine eigene Beweis-ISA (eISA) — potenziell am günstigsten zu beweisen, aber noch nicht entworfen und vermutlich mit neuen Versionen, wenn sich Beweiser ändern.

Was passt, hängt davon ab, was leanVM nativ ausführt; das Repository erkundet RISC-V und eine eigene leanISA mit sechs Befehlen.

Unveränderliche Verträge am Laufen halten. Weil die Identität jedes Programms seine ISA-Version enthält, speichert ein Pool eine program_id für immer, und jeder spätere Beweiser muss jede aktivierte Version beweisbar halten — so wie Clients die Regeln jedes Forks mitführen. Die Autoren diskutieren auch zwei Alternativen, die sie Vitalik und Alex zuschreiben: alte Beweise in neue einbetten und eine kanonische ISA einfrieren.

Warum das zählt. Das ist Infrastruktur, entscheidet aber, ob heute gebaute Privacy-Anwendungen sowohl einen Quantenbruch heutiger Kurven als auch künftige Änderungen an Ethereums eigenem Beweissystem überstehen.

Quelle: Ethereum Research, „Exposing an ISA for post-quantum proofs on Ethereum“, 8. Oktober 2026 — https://ethresear.ch/t/exposing-an-isa-for-post-quantum-proofs-on-ethereum/26136