EIP-6873 Stagnant EL

Preimage retention

Authors:

Execution clients must retain the preimages of addresses and slots accessed between the fork preceding the verge, and the verge itself.

Timeline

Glamsterdam

Guillaume Ballet

Withdrawn · Oct 23, 2025 · ACDE #223

Oct 23, 2025 · ACDE #223

Proposed

EIP Created Apr 14, 2023

Key Benefits

● Ensures data integrity during Verkle tree transition
● Maintains historical state accessibility
● Prevents data loss during migration
● Supports smooth transition to stateless model

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

No direct user-facing impact - this is purely infrastructure maintenance during the Verkle transition.

Application Developers

No impact on smart contract development as this handles backend state management during migration.

Wallet Developers

No impact on wallet development as preimage retention is handled transparently by the protocol.

Tooling / Infrastructure

Infrastructure providers need to understand preimage retention requirements for proper state reconstruction and proof generation.

Layer 2s

No direct impact on Layer 2 operations as this manages execution layer state transition details.

Stakers & Node Operators

Need to properly handle preimage data during the Verkle tree migration to maintain state verification capabilities.

CL Client Developers

No direct impact on consensus layer operations as this affects execution layer state management.

EL Client Developers

Must implement proper preimage retention mechanisms during state tree migration to ensure continuity of state verification.

North Star Goal Alignment

● Scale L1: Essential infrastructure component for Verkle tree transition, ensuring data integrity and availability during the state system migration.

Abstract

Enforce preimage collection by every node on the network from the fork preceding the verge, up to the fork. This is needed in case each node is responsible for their own conversion.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Let T_p be the timestamp of the fork preceding the verge, and T_v the timestamp of the verge.

EL clients MUST save the preimage of each address and slot hashes they produce during the execution of all blocks produced between T_p and T_v
EL clients MAY start storing preimages outside of this time range as well
Given a hash produced between T_p and T_v, EL clients SHOULD be able to show they have the preimage for that hash in their database
EL clients SHOULD be able to download the preimages of the address and slot hashes that were produced before T_v from a publicly-available datastore

Rationale

Switching to verkle trees require a complete rehashing of all tree keys. Most execution clients store all keys hashed, without their preimages, which as the time of print take up 70GB on mainnet. In order to make these preimages available to everyone, the following course of action are available to each user:

Restart a full-sync with preimage retention enabled
Download the preimages as a file

The second option is the only acceptable option in practice, as a full-sync requires the syncing machine to be offline for several days, and therefore should not be simultaneously imposed to the entire network. A file download, however, poses a problem of data obsolescence as new preimages will immediately need to be added to the list as the chain progresses and new addresses are accessed. Updating the preimage file is not sufficient, since it takes more than a slot time to download over 70GB.

To guarantee a timely availability of all preimages around the verkle transition time, each node is therefore responsible for updating the list of preimages between the fork preceding the Verge, and the Verge itself.

Backwards Compatibility

No backward compatibility issues found.

Reference Implementation

All clients already implement preimage retention, at least as an option.

Security Considerations

Needs discussion.