Implement ability to overwrite network parameter from checkpoint in Genesis

[jeremyletang]

What we have now

At the moment Network parameter are set like so:

• From the genesis block
• From a proposal
• Restore from a checkpoint

In case they are restored by a checkpoint the flow is the following:

• The network starts and parameter are setupe from genesis.
• The checkpoint is loaded and parameter from the checkpoints overwrite alll existing parameter.

The problem

Sometimes, a network parameter set in the checkpoint may not be desired in the same state after a restart. e.g:

• the payoutDelay has been set via proposal to 0s in the first mainnet, after the restart the actual desired behaviour is 3 days again, this could not be done without a new proposal
• The end of life of the network is a network parameter, although if it's restored from the checkpoint it could already be in the past.

Possible solution

We propose a way to either overwrite or ignore network parameters from the checkpoints and use setting from the genesis block instead, 2 implementations possible that I can think of:

• A new field is added in the genesis block, this field is a simple list of network parameter keys, which are to be ignored when the checkpoint is restored. The value of the network parameter will be the one set in the networkParameters map of the genesis block.
• A new field is added in the genesis block, the field is a map, like the network parameter map, with the value to overwrite when checkpoint is loaded.

I would go with the first one as it seems slightly simpler, and would be less prone to errors (e.g misconfigured genesis block) and we would keep a singlemapping of network parameter configuration, not 2, and a list of parmeters to exclude from the checkpoint reload.

[ze97286]

Not sure if there are any new thoughts on this but I have a concern regarding either of this approaches.

The problem is this: given a checkpoint file to load with a given hash for network parameters, which includes lets say for example payoutDelay=0. if upon loading network parameter we override some value with value from genesis (with whatever technique) e.g. we set payoutDelay to 72h - then if we take a hash it will not equal the hash given by the checkpoint file.

Maybe it's not a big issue cos someone can (?) still verify that the hash after the load corresponds to the hash(cp + overrides) and does not contain any other changes, but not sure it's legitimate.

[davidsiska-vega]

@ze97286 I think this is fine. I imagine the following workflow:

1. genesis is updated saying payotDelay from LNL should be ignored
2. genesis is updated to contain LNL file hash.
3. LNL transaction is submitteed all validators confirm that the hash matches what's in genesis
4. core now processes the LNL restore file and when it gets to setting payoutDelay it says ah, payoutDelay in LNL is 72h but genesis says 0s and it also says, ignore LNL value, so I'll ignore LNL value and continue processing the rest of the LNL file.

[ze97286]

@davidsiska-vega what I'm trying to say is that if we have an invariant that says hash(netparams) in the checkpoint must equal hash(netparams) after the restore from the same checkpoint (regardless of the procedure for restore), this invariant cannot hold. I don't know if it needs to hold but I think it can't with this required change because the value of the nework parameter in the checkpoint will be x, and post restore it will be y.

[davidsiska-vega]

Yeah, I don't know exactly when the hash is checked. If it's checked as you say (after the restore) then it indeed cannot work.

We should then probably adapt the invariant / check at a different point in the flow so it can work.