You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I've unblocked the issue of integrating Ultralight/Portal Network code into the client via Add ESM build to client #3359
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.
Hooking up our RPC endpoints related to block history to the Portal Network could be a very valuable next step.
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:HISTORY_PRUNE_EPOCHS
constant (basically 1 year in CL epochs). This change should happen within theEthereumFullService
/EthProtocol
part of theclient
and not in the devp2p package itself sincedevp2p
has no concept of block historyblockchain
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.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.
The text was updated successfully, but these errors were encountered: