Table of Contents

The intention of this doc is to go through what is needed for a transitioning away from the version beacon mechanism for upgrading Flow's execution stack to using Dynamic Protocol State.

Execution State Parameters

The proposal is that the following execution state parameters are added to the dynamic protocol state:

type ExecutionParameters struct {
    MeteringParameters

    ExecutionComponentVersion ComponentVersion

    CadenceParameters
}

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

type CadenceParameters struct {
	CadenceComponentVersion ComponentVersion
}

Metering Parameters

Metering parameters are currently kept on chain and read on every transaction. They are needed for fee calculations and for transaction/script stopping conditions. They are cached when read from the state and are invalidated if any of the registers needed to read them is touched.

Moving them into the dynamic protocol state seems reasonable since:

• they are integral to transaction and script execution (changing them changes the transaction/script results),
• having metering parameters in the dynamic protocol state would help with simplifying the code. Especially because:
  • reading the metering parameters also needs to be metered somehow to prevent issues which means there is a lot of exceptional code for that.
  • caching and cache invalidation for metering parameters is quite complex.
• having a single mechanism to inject on chain data into execution (the dynamic protocol state) would be better than having separate mechanisms

Execution Component Version format

One of the proposals in FLIP 296 is that the format execution component version is partial semver-like structure:

type ComponentVersion struct{
	Major uint
	Minor uint
}

I think this conceptually makes the most sense. The reasoning behind this is because FLIP 296 describes the component version as:

Component Version: version identifier for a component of the flow protocol. It references one specific behaviour of a sub-system (e.g. Execution Stack or HotStuff) of Flow, as prescribed by the protocol. It is important that the component versioning specifies how a node should behave on the protocol layer. We say that two specifications are equivalent, if they are describing the same behaviour - in other words, they are completely interoperable. Equivalent/interoperable component specifications have the same version.