bitpay
Erigon ETH Node Prune settings
Hi, What prune settings are possible when running an erigon ETH Node for bitcore-node? I like to keep the impact on diskspace at a minimun while not loosing functionality.
Currently, the pruning service (packages/bitcore-node/src/services/pruning.ts) only prunes invalid and old mempool transactions. The only setting for it is the age at which you want to prune the old mempool txs which you can set with the MEMPOOL_AGE environment variable (the default is 7 days).
It's worth noting that in the past I've run into errors syncing with an Erigon node. That was last August, though, so they might have fixed the issues, but YMMV.
@kajoseph I think you missunderstood. I am talking about pruning settings for the eth nodes. So like after bitcore-node took the transaction and block information and put it into the mongodb instance is it safe to prune that information from the eth nodes? Or are there are some functions inplace that rely on data not in the mongodb but on the nodes directly when using the bws.
My plan was to create a eth full node and let bitcore-node syncing the data into mongo db. After syncing is complete I would reconfigure the eth full nodes to prune data that is older than 3 months. My thoughts are that all the data would be in the mongo db and new blocks and transactions get to be copied in the mongo db just fine because they are obviously not older that 3 months. Would that work or is there some functionality in bws at least that just rely on the eth node to hold the data forever and not prune anything. If yes can the data be named because at least with erigon node you can set prune settings for specific data like h - prune history (ChangeSets, HistoryIndices - used by historical state access) r - prune receipts (Receipts, Logs, LogTopicIndex, LogAddressIndex - used by eth_getLogs and similar RPC methods) t - prune transaction by it's hash index c - prune call traces (used by trace_* methods)
Ah, in that case the only things bitcore-node goes to the eth node for that I'm aware of are an address' balance and ERC-20 events. The balance is not a problem, but pruning tx receipts will prevent past ERC-20 events from being callable.
See https://ethereum.stackexchange.com/questions/115056/can-a-pruned-node-do-contract-getpasteventstransfer-fromblock-startblock ^ that mentions geth of which erigon is a fork, but I'm not sure how much has changed between the two implementations. It might be worth asking on the erigon repo which flags are required to keep event history. From the 4 flags you listed I would guess you'd want to leave "r" off, but I can't say for certain that you can turn h and t on.
I hope this helps!