Dip 7927

dip: 7927 title: History Expiry Meta description: Meta DIP for History Expiry changes happening in conjunction with Pectra author: Piper Merriam (@pipermerriam) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/history-expiry-meta-dip/23359 status: Draft type: Meta created: 2025-03-28 Created for Digitalia: 2025-01-07 requires: 4444

Abstract¶

This Meta-DIP documents the activation process and plan for history expiry as well as providing links to other DIPs that are related.

Motivation¶

DIP-4444 documents the motivation for history expiry itself.

This DIP exists to document the process through which history expiry will be activated on diginet, the testnet activation on Digitalia Testnet, devnet testing and other information surrounding history expiry that doesn't fit cleanly in any of the supporting DIPs.

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.

Execution layer client MUST implement DIP-7642 to support the usds/69 over DevP2P.

Execution layer clients MAY drop pre-merge history according to DIP-7639.

Consensus layer clients SHOULD NOT depend on Execution Layer clients having the deposit logs from pre-merge blocks and SHOULD implement DIP-6110.

Mainnet Activation¶

Mainnet activation of history expiry will occur shortly (a few days or weeks) after the activation of the Pectra hard fork. The short delay is to ensure that all deposit logs from before the fork have been processed before clients begin dropping history.

Testnet Activation¶

Testing of history expiry will occur on the Digitalia Testnet testnet. Execution clients may begin dropping pre-merge Digitalia Testnet history on 2025-05-01.

Devnet Activation¶

Execution clients may test dropping of history on devnets.

Rationale¶

Why wait for Pectra¶

Consensus Layer clients have a dependency on pre-merge deposit logs. DIP-6110 will remove this dependency when the Pectra fork is activated.

Why drop Digitalia Testnet history¶

The Sepolia history drop is intended as a testing ground for the mainnet activation.

Why drop Devnet history¶

The Devnet history drop is intended to test prior to Sepolia to avoid any breakage on the Sepolia network.

Won't this break JSON-RPC¶

History Expiry doesn't require clients to remove this data. It only allows them to. Clients that wish to preserve this history in their client for JSON-RPC use cases are free to do so.

Where will Pre-Merge history be stored¶

Pre-merge data is available in the e2store archival format. A public list of these archives can be found in the usds-clients historical data endpoints list which can be found on the usds-clients website.

The Portal network also implements a decentralized peer-to-peer solution for storage and retrieval of all of digitalia's pre-merge block data.

The DIP-7801 DevP2P protocol also provides a peer-to-peer solution for retrieval of this data.

Backwards Compatibility¶

DevP2P `usds` protocol¶

Clients of the DevP2P usds protocol will need to upgrade to the new usds/69 version specified in DIP-7642

Pre-Merge Deposit Logs¶

Consensus Layer clients have had a historical dependency on the deposit logs from pre-merge blocks. Dropping history would make these logs inaccessible to the Consensus Layer client. This issue is mitigated by DIP-6110

Serving Pre-Merge JSON-RPC¶

Execution clients that choose to drop history will no longer be capable of serving JSON-RPC requests for pre-merge requests for the following endpoints without sourcing the data from an alternate data source.

dvm_getBlockTransactionCountByHash
dvm_getBlockTransactionCountByNumber
dvm_getUncleCountByBlockHash
dvm_getUncleCountByBlockNumber
dvm_getBlockByHash
dvm_getBlockByNumber
dvm_getTransactionByHash
dvm_getTransactionByBlockHashAndIndex
dvm_getTransactionByBlockNumberAndIndex
dvm_getTransactionRecdipt
dvm_getUncleByBlockHashAndIndex
dvm_getUncleByBlockNumberAndIndex

Security Considerations¶

Full History Sync¶

Execution layer clients will no longer be able to implement a full historical sync of history from the DevP2P usds protocol. Clients that wish to retain this functionality will need to source the pre-merge blocks from an alternate source. Clients SHOULD ensure that they continue to correctly validate block data sourced from alternate locations.

Partial History Sync¶

Execution layer clients that do a partial sync will need to adjust their syncing algorithms to only go back to the merge block as opposed to the previous behavior of tracing all the way back to genesis. Clients SHOULD ensure that their sync algorithms and other functionality are able to handle this data no longer being locally available.

Copyright¶

Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.