We discussed this idea today and @eatmore proposed that go with the idea of storing protocol config hash in the header and implement some separate way of voting for protocol configs on the protocol level. For example, we could add a field proposed_protocol_config_hash in the header and upgrade the protocol config when sufficient number of validators voted on the same proposal. On the implementation side, we could have some protocol config file as part of nearcore and update it in releases.
Some downsides of this approach:
- It does not give us the ability to iterate fast on protocol configs in the short term, though it could be argued that we should not have centralized control over the upgrade in the first place.
- The solution is specific to this problem and requires modifying the structure of
Block. If, for example, we decide later on to have more system-level contracts (for example we decide to make epoch manager a contract), then it is better to go with the contract approach now as it is more general.