SIP-7927: History Expiry Meta
Meta SIP for History Expiry changes happening in conjunction with Pectra
| Authors | Piper Merriam (@pipermerriam) |
|---|---|
| Created | 2025-03-28 |
| Requires | SIP-4444 |
Table of Contents
Abstract
This Meta-SIP documents the activation process and plan for history expiry as well as providing links to other SIPs that are related.
Motivation
SIP-4444 documents the motivation for history expiry itself.
This SIP exists to document the process through which history expiry will be activated on sila-mainnet, the testnet activation on SilaSepolia, devnet testing and other information surrounding history expiry that doesn’t fit cleanly in any of the supporting SIPs.
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 SIP-7642 to support the sil/69 over DevP2P.
Execution layer clients MAY drop pre-merge history according to SIP-7639.
Consensus layer clients SHOULD NOT depend on Execution Layer clients having the deposit logs from pre-merge blocks and SHOULD implement SIP-6110.
SilaMainnet Activation
SilaMainnet 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 SilaSepolia testnet. Execution clients may begin dropping pre-merge SilaSepolia 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. SIP-6110 will remove this dependency when the Pectra fork is activated.
Why drop SilaSepolia history
The SilaSepolia history drop is intended as a testing ground for the sila-mainnet activation.
Why drop Devnet history
The Devnet history drop is intended to test prior to SilaSepolia to avoid any breakage on the SilaSepolia 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 sil-clients historical data endpoints list which can be found on the sil-clients website.
The Portal network also implements a decentralized peer-to-peer solution for storage and retrieval of all of Sila’s pre-merge block data.
The SIP-7801 DevP2P protocol also provides a peer-to-peer solution for retrieval of this data.
Backwards Compatibility
DevP2P sil protocol
Clients of the DevP2P sil protocol will need to upgrade to the new sil/69 version specified in SIP-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 SIP-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.
sil_getBlockTransactionCountByHashsil_getBlockTransactionCountByNumbersil_getUncleCountByBlockHashsil_getUncleCountByBlockNumbersil_getBlockByHashsil_getBlockByNumbersil_getTransactionByHashsil_getTransactionByBlockHashAndIndexsil_getTransactionByBlockNumberAndIndexsil_getTransactionReceiptsil_getUncleByBlockHashAndIndexsil_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 sil 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
Copyright and related rights waived via CC0.
Citation
Please cite this document as:
Piper Merriam (@pipermerriam), "SIP-7927: History Expiry Meta [STAGNANT]," Sila Improvement Proposals, no. 7927, March 2025. Available: https://sips.sila.org/SIPS/sip-7927.