[Protocol Versioning] Deployment plan
@jordanschalm is already working on this.
Since Mar 10, 2025.
- Dominant language
- Go
- Stars
- 575
- Forks
- 217
- Avg merge
- 4d 20h
- Merged PRs (30d)
- 9
Description
Overarching Product Goal
This issue is part of Epic #6999. The overall goal is to evolve Versioning of Execution Stack to use the Dynamic Protocol State, and subsequently employ this versioning information for
- coordinating EN HCUs (see Flip 298 for more context on product relevance and impact)
- the ANs to supports script execution across breaking HCU version boundaries (see OKR description for more context on product relevance and impact)
This issue is part of 1.
Detailed Task Description
Investigate tradeoffs, effort and complexity:
-
Deploying the new Versioning Mechanism will require a protocol-level update, because we are adding new logic to the protocol state.
-
All nodes need to support the new behaviour. It could be a rolling software deployment proceeding as follows:
- 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
-
Depending on the technical complexity of deploying the new Versioning Mechanism via a rolling update, we could consider including this feature as part of the next spork.
Document findings
Execution State Parameters in the Dynamic Protocol Statein and make a decission
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.