ETH - Pruning Setting to keep 1 month worth of historical data and serve L2 blockchains

[andreclaro]

Hello Reth experts,

What's the recommended pruning configuration to keep 1 month worth of historical data in a L1 Ethereum Node, which will be used as RPC node by clients and L2 blockchains like Arbitrum, Optimism, Base, Mantle, Blast, etc.

We have observed the following issues in optimism and base after switching the L1 node from geth to reth (with pruning enable):

op-node[351840]: t=2024-08-05T11:38:14+0000 lvl=warn msg="Engine temporary error" err="temp: failed to fetch receipts of L1 block 0xd3d72bdaf2f7baacce52072e4385acff6bf0777e247e0dda81a426b9e41de892:6365678 (parent: 0x0610b8348aee24e4bcb17e028eef0f9d6ebd51c0fe127022145d296691458508:6365677) for L1 sysCfg update: receipt 0 has unexpected nil block number, expected 6365678"

Our current pruning configuration is:

[prune.parts]
# Keep 1 month (30 days) worth of historical data, we just need to keep the last 216000 blocks: 60*60*24*30/12=216000
# Sender Recovery pruning configuration
sender_recovery = { distance = 216_000 } # Prune all transaction senders before the block `head-216000`, i.e. keep transaction senders for the last 100001 blocks

# Transaction Lookup pruning configuration
transaction_lookup = { distance = 216_000 } # Prune all transaction lookups before the block `head-216000`

# Receipts pruning configuration. This setting overrides `receipts_log_filter`.
receipts = { distance = 216_000 } # Prune all receipts before the block `head-216000`

# Account History pruning configuration
account_history = { distance = 216_000 } # Prune all historical account states before the block `head-216000`

# Storage History pruning configuration
storage_history = { distance = 216_000 } # Prune all historical storage states before the block `head-216000`

[andreclaro]

What is the recommended setting for block_interval in this case? Use default value or custom one?

[mattsse]

@joshieDo @shekhirin can this be done with the distance setting?

I assume for OP this should be adjusted so that 30 days are calculated with the 3s blocktime

Keep 1 month (30 days) worth of historical data, we just need to keep the last 216000 blocks: 606024*30/12=216000

[andreclaro]

This question is related with Ethereum node configuration... For OP and Base, we are still running Geth.

I updated the title of the discussion and the description as well to be much clear. Thanks

[andreclaro]

Hi @mattsse @joshieDo @shekhirin , can you help with my questions? Thanks 🙏🏽

[onbjerg]

for ethereum, the same logic applies, you can use the distance setting with 216000 blocks worth of data, which corresponds to roughly 30 days since the block time is 12 seconds.

use the distance setting like in the example here https://reth.rs/run/config.html#the-prune-section

as for the error, are you sure its in the expected range?

[andreclaro]

We also noticed that the reth node gets out of sync whenever it is performing the pruning. Can someone comment on this observation?

[qedgardo]

Do you have any updates on this? Could you guys share the recommended prune settings for keeping 216000 blocks? What would be a proper block interval to avoid the node running out of sync?

[onbjerg]

see here #10126 (reply in thread)

for block interval, it really just depends on your hardware. higher block interval = does not prune as often. you can leave it as default if you're in doubt:)

[qedgardo]

Thanks for answering @onbjerg . What would be the default block interval? IIUC the docs say by default doesn't prune at all.