[Protocol Versioning] Execution Parameters in the Dynamic Protocol State

[AlexHentschel]

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

1. coordinating EN HCUs (see Flip 298 for more context on product relevance and impact)
2. 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

The goal of this issue is to in extend the Protocol State's data model to include the Execution Parameters outlined in
Execution State Parameters in the Dynamic Protocol State

ExecutionMeteringParameters Updatable[ExecutionMeteringParameters]
ExecutionComponentVersion   Updatable[MagnitudeOfChangeVersion]
CadenceComponentVersion     Updatable[MagnitudeOfChangeVersion]

(this is a flat representation of the protocol parameters described in Execution State Parameters in the Dynamic Protocol State, which Janez was fine with)

Note that the description in Execution State Parameters in the Dynamic Protocol State is simplified. Specifically, Janez wants that the protocol state reports the current version (described in the notion doc) but also the ability to schedule a future version change (not described in Janez' notion doc, because he isn't familiar with how that should be implemented). I think it would be necessary to track the current version and additionally include a ViewBasedActivator for scheduling future changes of the "current version".

type ExecutionMeteringParameters struct {
	ExecutionEffortParameters map[uint]uint64
	ExecutionMemoryParameters map[uint]uint64
	ExecutionMemoryLimit uint64
}

// MagnitudeOfChangeVersion is intended as an intuitive representation of the “magnitude of change”.
// 
// CAUTION: this versioning representation DEVIATES from established Semantic Versioning. Any two
// different versions of the Execution Stack are considered incompatible. In particular, two versions only
// differing in their minor, might be entirely downwards-INCOMPATIBLE. 
// We generally recommend to use Integer Versioning. The MagnitudeOfChangeVersion scheme should
// be only used when there is a clear advantage Integer Versioning which outweighs the risk of falsely 
// making compatibility assumptions by confusing this scheme with Semantic Versioning!
//
// MagnitudeOfChangeVersion helps with an intuitive representation of the “magnitude of change”. 
// For example, for the execution stack, bug fixes closing unexploited edge-cases will be a relatively
// frequent cause of upgrades. Those bug fixes could be reflected by minor version bumps, whose
// imperfect downwards compatibility might frequently suffice to warrant Access Nodes using the same
// version (higher minor) across version boundaries. In comparison, major version change would generally
// indicate broader non-compatibility (or larger feature additions) where it is very unlikely that the Access
// Node can use one implementation for versions with different major. 
// We emphasize again that this differentiation of “imperfect but good-enough downwards compatibility”
// is in no way reflected by the versioning scheme. Any automated decisions of compatibility for different
// versions are to be avoided (including versions where only the minor is different). 
// Engineering teams using this scheme must be aware that the MagnitudeOfChangeVersion is easily
// misleading wrt to incorrect assumptions about downwards compatibility. Avoiding problems (up to and
// including the possibility of mainnet outages) requires continued awareness of all engineers in the
// teams working with this version. The engineers in those teams must commit to diligently documenting
// all relevant changes, details regarding magnitude of changes and if applicable “imperfect but 
// good-enough downwards compatibility”. 
type MagnitudeOfChangeVersion struct {
	Major uint
	Minor uint
}

// Updatable represents some protocol parameters, which _always_ have a current value.
// Optionally, updates may be scheduled to overwrite the current value when reaching
// or exceeding a specified view.
type Updatable[T any] struct {
	// CurrentValue is the value that is active after constructing the block
	// that this Protocol State pertains to.
	CurrentValue T

	// Update is optional and is nil, if no value update has been scheduled yet.
	// This field will hold the last scheduled update until a newer update
	// directive is received, even if the value update has already happened.
	// The update should be applied when reaching or exceeding the ActivationView.
	Update *ViewBasedActivator[T]
}

There is a detailed documentation of the reasons for using the $\textnormal{\texttt{major.minor}}$ versioning convention given in the Execution State Parameters in the Dynamic Protocol State, section Decision on using versioning major.minor.

Definition of Done

• Protocol State's data model extended to include the parameters above
• API methods in KVStoreReader to query the current values and the Value Update (if one has been scheduled)

Service events to update the values and the state machine logic for actually applying or rejecting a request for scheduling an update are not part of this issue.

[AlexHentschel]

Jordan has created a very early draft PR, illustrating how the execution parameters could be represented in the protocol state: PR #7020

We have discussed this draft PR in detail, with decisions and next steps documented in notion doc
Execution State Parameters in the Dynamic Protocol State, section 2025-03-04 Review of implementation proposal

[jordanschalm]

Addressed by #7020