Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

EIP-8357: EVM Verification Key Registry

Table of Contents

EIP-8357 is a draft Core EIP that tells contracts which verification key L1 has approved for proving EVM execution in each fork. It is the one piece native rollups need on top of EIP-8288. This page summarizes the design; the EIP is authoritative:

Motivation

EIP-8288 verifies each proof dependency against an explicitly supplied verification_key_hash, a hash of the STARK verification key. It does not tell contracts which hashes L1 recognizes as its own EVM program, which one is current, or which input schema each program accepts. A native rollup that hard-coded these values would have to upgrade through its own governance at every L1 feature fork, or remain on an older EVM: exactly the governance risk native rollups are meant to remove.

EIP-8357 records these values once, in shared L1 state that every contract can read. Verifiers keep accepting exact hashes, while each rollup chooses whether to follow the current entry or pin a historical one.

How the registry works

The registry is an ordinary EVM contract at a fixed address, 0x00005e9c1447c1a05a642ec9eb76d9c125468357. Anyone can deploy it through the EIP-7997 deterministic factory with a fixed salt, so the address is bound to the exact bytecode.

Its state is:

  • a mapping from each registered verification_key_hash to the schema_id of the stateless input its program accepts, which also selects the fork rules the program executes (see Specification); and
  • the current verification_key_hash.

Entries are append-only: a registered hash is never deleted, overwritten, or revoked.

Reads. Any caller sends a single 32-byte word:

  • zero requests the current entry;
  • a nonzero value requests that exact registered hash.

The registry returns verification_key_hash || schema_id, and reverts if no such entry exists.

Updates. Only SYSTEM_ADDRESS can update the registry, and only in the first block of a hard fork, before any transactions are processed:

  • a 64-byte registration adds a new hash with its schema_id and makes it current;
  • a 32-byte reactivation makes a previously registered hash current again, keeping its schema_id.

Each new or reactivated hash is specified by its own Core EIP, which names the L1 feature fork whose EVM semantics it represents and the schema_id its program accepts. The fork that activates EIP-8357 also registers the initial hash. The system call’s gas does not count toward the block, and the block is invalid if the call fails.

How native rollups use it

A native rollup reads the registry when it advances its L2 state and uses the result in two places:

  • it requires the EIP-8288 dependency in the transaction to carry the returned verification_key_hash; and
  • it uses the returned schema_id to reconstruct the proof’s public output, which commits to it (see Proof statement).

Each rollup chooses one of two policies:

  • Follow current: query with zero and accept only the current hash. When a hard fork updates the registry, the rollup moves to the new EVM automatically, without changing its code or storage.
  • Pin: query a stored historical hash, and keep that fork’s EVM semantics after L1 moves on. This gives the rollup its own upgrade window, at its own risk.

The full contract is shown in the Specification.

Security considerations

  • The registered hash must be sound. If a hash for an incorrect program were registered as current, an attacker could prove false state transitions for every rollup following it.
  • Following current means adopting each fork’s key. Proofs generated under the previous key may fail after the switch, and a rollup that cannot produce proofs under the new key may halt.
  • Pinning transfers maintenance risk. Registered hashes are never revoked, even if proofs under them are later considered insecure. L1 does not maintain historical entries, and a pinned rollup must detect vulnerabilities and migrate on its own.