Multiple sources of truth for defaults

[mariari]

Following #1033, there seems to be at least 3 locations where default values can reside and change

• https://github.com/anoma/namada/blob/main/genesis/dev.toml
• https://github.com/anoma/namada/blob/main/genesis/e2e-tests-single-node.toml
• Inside the Genesis function with the dev feature
  • https://github.com/anoma/namada/blob/main/apps/src/lib/config/genesis.rs#L924
  • https://github.com/anoma/namada/blob/main/apps/src/lib/config/genesis.rs#L1001

I understand that for end-to-end (e2e) tests, that parameters might want to be tweaked, or on a dev machine, however with so many sources of these values, tweaking a default across the system that applies to dev, e2e and the mainnet one may forget to update one of these sources and cause an inconsistency in either testing the system or on the live system itself. Judging by repeating the same values in all three sources, I'd argue the chances are likely to overlook changing one value without properly propagating the change.

[tzemanovic]

yeah, in #685 we're gonna use same source for local net and e2e tests and the "dev" feature is gonna be removed completely. I don't think there should be any correlation between the param values in the different networks, except for the local and e2e tests, which will be the same. An automated "devnet" (private testnet with multiple deployed validators), public testnet and mainnet configuration are all independent from each other and the local setup. For sensitive parameters, there will be unit tests and toolinng for checking any possible validity rules (e.g. PosParams::validate)

[mariari]

yeah, in #685 we're gonna use same source for local net and e2e tests and the "dev" feature is gonna be removed completely. I don't think there should be any correlation between the param values in the different networks, except for the local and e2e tests, which will be the same. An automated "devnet" (private testnet with multiple deployed validators), public testnet and mainnet configuration are all independent from each other and the local setup. For sensitive parameters, there will be unit tests and toolinng for checking any possible validity rules (e.g. PosParams::validate)

Thanks, another major issue that has wasted over 6 hours is the inconsistent naming of the toml files as well

[token.apfel] versus [token.Apfel] in the e2e.toml versus dev.toml has caused loading issues in trying to diagnose some issues.