Table of Contents

Context

💡 👉 Protocol Version Upgrade Mechanisms Discussion (flow forum post) 👈

Status Quo

Strong limitations of existing Height-Coordinated Updates [HCU] for Execution Nodes [ENs]

1. Only implemented for ENs

2. Requires time-sensitive (manual) coordination upfront and node operator standby during HCU

3. HCU mechanism only specifies minimum software version at specific block boundary (but not max). Only safe if all updates are 100% downwards compatible.

   Failure scenario:

   • Operator brings up node from recent historical state (pre-HCU)
   • Uses latest EN image (post HCU) => software is happy and produces possibly wrong results

[Recap] Primitives the Dynamic Protocol state provides for coordinating protocol upgrades

Dynamic Protocol State in a nutshell

• Dynamic Protocol State includes a framework for storing a snapshot of protocol-defined parameters and supplemental protocol-data into each block. Think about it as a key value store, where you can store values.
• You provide a custom state machine for updating the values of your key-value pair. Correct application of this state machine (i.e. correct evolution of data in the store) is guaranteed by BFT consensus.
• already used for Epoch switchover

Specifically for coordinating software version upgrades:

• There is a framework for view-based triggers: if we cross a pre-specified view, some specific action can be triggered for this fork.