[DONOTMERGE] move chain config to validated state

[imabdulbasit]

Closes #1475

Move ChainConfig to ValidatedState to allow updates

[imabdulbasit]

@sveitser @jbearer This doesn't look right. Do we need to add ValidatedState type to this trait and pass that as the parameter to from_transactions

[jbearer]

Ugh yes we do (or equivalent). But the bigger problem is this means the builder will need to be aware of the ValidatedState at each point. This is fundamental because a parameter of block building (max size) is now being made variable.

In theory this is fine, the builder can compute the state by replaying each proposal it sees, but I don't know if it currently has all the information it needs from HotShot to call validate_and_apply_header. We'll need to discuss this with @move47 and @nyospe

[nyospe]

I don't believe we do, and I'm not sure it will be trivial to add.

[nyospe]

Even if we maintain the state as suggested, we will need a mechanism to recover when we miss a proposal...

[jbearer]

That part is built into the sequencer implementation of ValidatedState. validate_and_apply_header will automatically fetch missing state as needed as long as the InstanceState contains a valid peer URL

[jbearer]

It occurs to me that we will need catch up for this as well. The ValidatedState will need to have a ResolvableChainConfig, not a ChainConfig, so that we can implement from_header by just taking the Commitment<ChainConfig> from the header if the full ChainConfig is not available. Then we'll need catchup for validated state:

• As a heuristic, if the Commitment<ChainConfig> matches the genesis ChainConfig from instance_state, we can just use that. This will work in almost all cases.
• In the case where our node was out of sync while an upgrade was happening, we might have a ValidatedState with a Commitment<ChainConfig> that doesn't match any complete ChainConfig that is known to us. In this case we would have to fetch the complete ChainConfig from a peer via an endpoint like GET /catchup/:view/:height/chain-config or maybe GET /catchup/chain-config/:commitment

[imabdulbasit]

as discussed with @jbearer
The from_transactions function will be async. We will pass an additional parameter, ValidatedState.

ResolvableChainConfig contains either a full ChainConfig or just a commitment.

• The commitment in ResolvableChainConfig exactly matches the instance's ChainConfig (genesis). In this case, we simply return the instance's ChainConfig.
• The ResolvableChainConfig contains a full ChainConfig.
• The commitment from ResolvableChainConfig does not match the node instance's chain configuration. In this case, we need to perform a catchup.