Repository navigation
[Protocol Versioning M2] Version of system transaction tracked by Dynamic Protocol State #8080
Description
[based on conversation with @peterargue Oct, 23, 2025]
During the system chunk, Execution Nodes (ENs) process some protocol-determined list of work. Conceptually, the system chunk executes a sequence of (reduced) transactions. Transaction may have different privileges ("root", "user-space").
Currently, this is largely hard-coded in the execution stack, and upgraded via Hight-Coordinated Upgrades (HCU). From the perspective of the software stack, there exists a clear before-after relation. However, the Access Node (AN) should be able to serve data across different HCUs, including the system chunks. In other words, an AN has to manage different protocol conventions / implementation to generate the content of the system chunk.
EPIC: Therefore, the protocol state should contain some "version" describing the specifics of the system chunk (suitable details tbd).
Activity
fxamacker commentedon Nov 10, 2025
I synced with @peterargue to add
SystemCollectionComponentto execution upgrades redesign using Dynamic Protocol State last week.I created redesign proposal to include
SystemCollectionComponentalong with existing cadence and execution components.VersionUpgradesmap is used instead of specifying each component explicitly so that we can support new component types (in the future) without upgrading service events or upgrading protocol state. We only have 3 types of components now so using a map will allow us to add new types of components in the future (up to 255) if needed.BTW, the idea to use a single integer as version number (instead of "major.minor") was discussed even before I got involved with this project but the topic came up again. I think we can use a single integer version number (
uint16) plus anUpgradeKindenumeration (uint8) instead of "major.minor". This provides the simplicity of single integer version (individually for each component type) and theUpgradeKindcan be used to describe the kind of upgrade for each component (e.g., bugfix vs optimization vs feature, etc.). Since we can have up to 255 kinds, we can even specify a kind that lets us know new Cadence language feature was added.