EIP-8357: On-Chain-Register für freigegebene EVM-Verifikationsschlüssel
Serguey Asael Shinder2 Min. LesezeitEin neuer Ethereum-Verbesserungsvorschlag, EIP-8357 „EVM Verification Key Registry“, wurde am 14. Oktober 2026 als Entwurf in das EIPs-Repository aufgenommen. Verfasst von Luca Donno und am 30. Juli angelegt, ist er ein Core-Vorschlag für Native Rollups – Rollups, die Ethereums eigene Ausführungsumgebung und deren Upgrade-Prozess übernehmen, statt einen eigenen Verifier zu pflegen.
Welche Lücke er schließt. Der Entwurf baut auf EIP-8288 auf, das Beweise gegen vom Aufrufer übergebene Hashes von Verifikationsschlüsseln prüft. Was EIP-8288 laut Begründung nicht liefert: eine Möglichkeit für Verträge zu erfahren, welche Hashes L1 anerkennt, welcher aktuell ist und welches Eingabeschema das jeweilige Beweisprogramm erwartet. Das Schema braucht man, um die öffentliche Ausgabe des Programms zu rekonstruieren. Wären diese Werte fest eingetragen, müsste jedes Rollup bei jeder L1-Feature-Fork eine eigene Governance-Abstimmung durchlaufen oder bliebe standardmäßig auf einer älteren EVM.
Was das Register ist. EIP-8357 definiert einen Systemvertrag an einer festen Adresse (im Entwurf 0x00005e9c1447c1a05a642ec9eb76d9c125468357), der für jede registrierte L1-Feature-Fork den kanonischen Hash des EVM-Verifikationsschlüssels und die schema_id der zustandslosen Eingabe speichert, die das EVM-Programm dieser Fork annimmt. Der Vertrag hält einen current_verification_key_hash; ein Aufrufer kann den aktuellen oder einen bestimmten historischen Eintrag abfragen. Der Null-Hash ist für die Abfrage des aktuellen Eintrags reserviert und darf nicht registriert werden. Der Schlüssel-Hash ist das 32-Byte-Feld, das EIP-8288 für sein STARK-basiertes Verfahren festlegt.
Was ein Rollup gewinnt. Die Zusammenfassung nennt zwei Wege: Ein Native Rollup kann L1-EVM-Upgrades automatisch folgen, indem es stets den aktuellen Eintrag liest, oder bewusst bei einer historischen EVM-Fork bleiben, indem es einen bestimmten Hash festschreibt. In beiden Fällen wird die Entscheidung zur Eigenschaft des Rollup-Vertrags statt zu einem wiederkehrenden Governance-Ereignis.
Stand. Der Vorschlag nennt eine lange Kette von Abhängigkeiten – darunter die EIPs 161, 1014, 1559, 7910, 7928, 7997, 8025, 8037 und 8288 –, einem bestimmten Netzwerk-Upgrade ordnet der Entwurf ihn nicht zu. Als Entwurf kann sich der Text noch stark ändern; diskutiert wird auf Ethereum Magicians.
Quelle: EIPs-Repository, EIP-8357 „EVM Verification Key Registry“ (aufgenommen am 14. Oktober 2026) — https://github.com/ethereum/EIPs/commit/3adac4e2ae4cda00f5f6401f891f5faaff4abe53