Version Execution Stack via Dynamic Protocol State

[AlexHentschel]

This is an epic for bundling all tasks related to version the Execution Stack via Dynamic Protocol State.

motivation and importance of this work

The Dynamic Protocol State includes a framework that has been developed based on the learnings of the existing HCU mechanism. It provides us with the ability to perform general purpose upgrades of the the flow protocol and is much more generally applicable and robust compared to the initial HCU mechanism (only applicable for upgrading the Execution Stack).

• We are starting to use the Dynamic Protocol State for coordinating upgrades of other parts of the protocol.
  We want to utilize the same framework as for execution stack upgrades, to reduce code and intellectual complexity that would
  otherwise result from using significantly different approaches.
• Midterm goal: upgrades of the execution stack are by far the most frequent. By utilizing the Dynamic Protocol State for those upgrades, we
  want to generate learnings on where the new framework should be improved. Specifically, we want to avoid extending the old HCU mechanism in a way that is incompatible with the Dynamic Protocol State and needing to be rewritten later.
• Longer-term goal: Access Nodes [ANs] can decide on whose blocks’ execution states they can run scripts for across different version of the execution stack.

For more details on the advantages of the new Protocol-State-mediated upgrade framework, please see FLIP 296.

• [Protocol Versioning] Execution State Parameters in the Dynamic Protocol State #7000
• Once the previous issue (☝) is done, we can store the Execution Stack Version (and other protocol parameters controlling the execution) in the Dynamic protocol state. Adding this functionality to make updates to these parameters in the Protocol State is part of this step.
  • implement Service Events on the protocol layer only (flow-go) for requesting to schedule a value update
  • Janez to define the rules by which request for scheduling an update should be accepted or rejected
  • in the Protocol State, implement this logic for accepting or rejecting request for scheduling an update as a KeyValueStoreStateMachine and add this to the Protocol State's EvolveState method
• Add or modify Governance Smart Contracts to emit the newly defined Service Events
• to the Execution Node, add a new StopControl to work with the Protocol State (we probably wan to keep the old logic for now, to still be able to do HCU's in the old style in the interim)
• Deployment plan:
  • this will require a protocol-level update, because we are adding new logic to the protocol state
  • it can be a rolling software deployment, all nodes need to support the new behaviour - so we are using the protocol-upgrade as a gate for nodes to stop participating that haven't been upgraded
  • after the protocol has passed the gate-view, we can start using the new service events to schedule Execution Stack upgrades