EIP-4444 - Tracking Issue

[acolytec3]

EIP-4444 is on the horizon and it's time we start thinking about the implications for the client. Here are what I believe the main changes required in the client to be:

• Stop serving block header, block bodies, and receipts older over devp2p where the data is from a block older than the HISTORY_PRUNE_EPOCHS constant (basically 1 year in CL epochs). This change should happen within the EthereumFullService/EthProtocol part of the client and not in the devp2p package itself since devp2p has no concept of block history
• Add a feature to prune older blocks
• Our default sync mode needs to be Beacon Sync paired with a CL client (aka "Checkpoint Sync").
• We should consider whether it makes sense to retire Full Sync, or else rewrite it to use the Portal Network as the means of retrieving the block history.
• We need to consider the upstream implications for the blockchain class. The EIP specifically suggests treating the weak subjectivity checkpoint as "genesis" for purposes of syncing so we need to evaluate what/if any are the implications of this.
• We should update our RPC endpoints impacted by this (eth_getBlockByNumber, eth_getBlockByHash, eth_getLogs, eth_getTransactionReceipt to potentially use Portal Network backends)

There's probably more here but a first step in supporting 4444 should be to confirm that we can sync our client only using checkpoint sync and then setup our sync in such a way that it doesn't backfill older blocks beyond the 1 year mark.

[acolytec3]

Some additional thoughts on this.

1. I've unblocked the issue of integrating Ultralight/Portal Network code into the client via Add ESM build to client #3359
2. We can now explore full sync using only Portal Network backends. The current Portal Network History Network probably doesn't have a complete pre-merge set of blocks available but we can certainly flesh out the code necessary to do Full Sync directly from the Portal Network and see how it goes.
3. Hooking up our RPC endpoints related to block history to the Portal Network could be a very valuable next step.