nethermind
nethermind copied to clipboard
Don't make mainnet.cfg the default
Describe the bug We've introduced an unexpected breaking change in 1.13.4: In case you do not use your own configuration file, mainnet.cfg settings are used by default and since the update, SnapSync is enabled by default for the mainnet configuration, which means it's enabled for your node too. It will cause a problem in networks without SnapSync supporting nodes.
Expected behavior Nodes without a config file shouldn't use the mainnet.cfg file as a default.
Maybe we should introduce a default.cfg based on the mainnet.cfg just not to break the current behavior?
The similar problem: https://github.com/NethermindEth/nethermind/issues/4282 Pruning.None for archive nodes
Not sure how this would solve any issues?
@dceleda @smartprogrammer93 @LukaszRozmej @MarekM25 I don't get it TBH When someone runs Nethermind.Runner without config then is supposed to run Nethermind on mainnet. I don't get a part with "in networks without SnapSync" - how this can be reproduced?
@dceleda @smartprogrammer93 @LukaszRozmej @MarekM25 I don't get it TBH When someone runs Nethermind.Runner without config then is supposed to run Nethermind on mainnet. I don't get a part with "in networks without SnapSync" - how this can be reproduced?
https://github.com/NethermindEth/nethermind/issues/4281
I believe the whole idea behind this issue and PR is obselete. It was in the early days of SnapSync when suddenly in the mainnet config snapsync became on by default. Which broke some nodes that have not synced using snapSync. But i think it is now too late to introduce this change
I believe the whole idea behind this issue and PR is obselete. It was in the early days of SnapSync when suddenly in the mainnet config snapsync became on by default. Which broke some nodes that have not synced using snapSync. But i think it is now too late to introduce this change
Does it mean that the mainnet config is not the default one anymore and whenever we introduce a change to that file it won't affect custom networks without a config file? As for my understanding, the SnapSync case was just an example of what can go wrong in such scenario.
No mainnet config is still the default. Its just that all private network probably upgraded and adjusted to the change. The change to snapsync being on by default was introduced months ago. So i dont think it is important to revert it by default now. Furthermore, this might break existing setups where they do not specify mainnet config and expect snap to be on
To be honest it looks like a broken feature/bug - to use the mainnet config as the default one. But since the last problem (SnapSync config change), we haven't faced any new ones so maybe we should just close the item.? WDYT
IMO changing default config to default.cfg which is mainnet without snap sync is a very problematic solution - many users will unconsciously run it and be frustrated by sync time. We will have a lot of new, syncing nodes (and maybe even with never-ending sync), we can scare many new users because of that. Every network has it's own config file with proper setup. If user is trying to run network which doesn't have config file, then there is a need to create proper one and user have e.g. discord to ask for help with that, or can create an issue here in case of any troubles. I think we have way more mainnet users than ones trying to run private networks and I expect the second ones to be more technically advanced and able to prepare proper config. We are ethereum client and IMO it's fine to have ethereum mainnet config as default one and make usage of Nethermind as mainnet client as easy as possible