Erigon’s datadir way larger than what Polygon's documentation specifies. What can I do to reduce it?

[Petter-s]

System information

Erigon version: 2022.08.3-alpha OS: kubuntu

I'm trying to run a Polygon full node using Erigon. According to the Polygon documentation, the minimal hardware configuration for that is 1.2 TB SSD in terms of space. To that end, I bought a 2 TB drive to run my node to ensure that I am reasonably future-proof.

I have now been syncing my node for a few days (its still not done), Erigon’s datadir is the only thing on the drive and it now only has 50 GB of space left!. And the datadir is still growing so any time now I expect that my Erigon node will halt due to being out of space. Which is pretty heartbreaking since I bought the SSD specifically to run a Polygon node.

Why is Erigon using hundreds of GB more than what the official Polygon documentation suggests?

Are there any settings related to pruning/snapshots etc. I can change when running my node that will reduce the hdd space required? What Erigon settings will produce the smallest possible datadir?

This is how I currently have Erigon configured:

erigon –chain=bor-mainnet --bor.heimdall=https://heimdall.api.matic.network/ --datadir="/media/pett3r/M.2 External/polygon_bor_data" -ws

[enriavil1]

Using --prune htrc will give you the smallest possible size.

[enriavil1]

Using prune flags will require a resin I believe.

[AskAlexSharov]

Erigon by default is an Archive Node

[Petter-s]

Erigon by default is an Archive Node

Oh, I had missed that important detail! Thanks for letting me know, that would completely explain the disk usage.

How can I configure Erigon to run as a regular (non-archive) full node instead? I've looked through the Erigon configuration flags but I don’t see any –gcmode flag which is what I guess you use in Geth to toggle between node types. What flag is used in Erigon?

[AskAlexSharov]

"erigon --help | grep prune"

[Petter-s]

--prune htrc

Thanks, I've looked at the Erigon prune help now, but its still not obvious to me how the flag should be set for a regular Polygon full node. Here is why:

From what I've read, an Ethereum full node (non-archive) normally only stores the 128 most recent states, or only 64 if fast sync is enabled. Which, given that Ethereum has a block time of ~13 seconds, should correspond to roughly 15-30 minutes of data.

Polygon however, has a much shorter block time of about 2 seconds. Does that mean that a Polygon full node should store somewhere in the region of 400-800 of the most recent states instead of 64/128? Such that the stored data still captures the past 15-30 minutes. Or is it irrelevant how much wall-time the states corresponds to and it should still be 64/128?

I'm assuming --prune.h/t/r/c.older are the appropriate Erigon flags to use for regulating this. Would this then be the correct way of running a Polygon full node:

erigon --chain=bor-mainnet --bor.heimdall=https://heimdall.api.matic.network/ --datadir="/media/pett3r/M.2 External/polygon_bor_data" --ws --prune.h.older 128 --prune.t.older 128 --prune.r.older 128 --prune.c.older 128

or this?

erigon --chain=bor-mainnet --bor.heimdall=https://heimdall.api.matic.network/ --datadir="/media/pett3r/M.2 External/polygon_bor_data" --ws --prune.h.older 800 --prune.t.older 800 --prune.r.older 800 --prune.c.older 800

Both 128 and 800 seems suspiciously far off the default Erigon value of 90000. I would hate to misunderstand this and set the flags wrong again and lose weeks of unnecessary syncing a second time.

[AskAlexSharov]

// FullImmutabilityThreshold is the number of blocks after which a chain segment is
// considered immutable (i.e. soft finality). It is used by the downloader as a
// hard limit against deep ancestors, by the blockchain against deep reorgs, by
// the freezer as the cutoff threshold and by clique as the snapshot trust limit.
FullImmutabilityThreshold = 90000

--prune.h.older 128 - means if network will have re-org longer than 128 blocks - your node will not able to handle it (it will stuck with "invalid state root error").

I don't know - can Polygon network have re-orgs longer than 128 blocks or not. And if yes - what is the probability. Better ask Polygon team - for example @0xKrishna

FYI:

• Erigon does store StateHistory in compact-enough way. So, likely you will NOT win much space by changing h.
• Erigon does store Receipts in NOT-compact-enough way. So, likely you will win much space by changing r.

[github-actions[bot]]

This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.

[Zeesna4141]

@Petter-s just curious, did you end up figuring this out? How much storage were you able to save by pruning? Also did you end up having issues with 128?