SIMD-0161: SBPF versioning and feature gating #161
Conversation
Lichtso
changed the title
Lichtso
changed the title
Lichtso
force-pushed
the
sbpf-feature-gating
branch
from
5ad5633
to
cba7237
Compare
Lichtso
force-pushed
the
sbpf-feature-gating
branch
from
cba7237
to
ab8e75a
Compare
| Block explorers are recommended to display this SBPF version field for program | ||
| accounts. | ||
|
|
||
| For each SBPF version two feature gates will control its availability: |
There was a problem hiding this comment.
I'm not sure that we need such a strict system. I think we could probably have several versions active and deployable at the same time, without forcing people to update toolchain and redeploy or pay extra costs.
Take the following examples:
-
dynamic frames: from the vm perspective, it is cheaper to use dynamic frames, because programs potentially page in less memory if an X-deep call stack fits in 1 page vs taking X pages because of fixed framing. We might want to push people to update to increase performance.
-
the
sub immoperand swap change: this doesn't materially change anything. It's a nice thing for us to fix for aesthetic reasons, but it doesn't really change anything for developers.
I think I'd prefer an ad-hoc system where depending on the impact of a new SBPF version, we decide whether and how to rug earlier versions (in practice I expect this to happen very rarely).
There was a problem hiding this comment.
Mandating that all deployments are targeting the newest version does not force anybody to redeploy. It only means that dapp devs have to keep their toolchain updated when they re/deploy. You are right in that it is not necessary to be this strict, but it has the nice effect of allowing us to get more testing exposure for the newest toolchain version.
| | SBPF version | becomes deployable and executable | ceases to be deployable | | ||
| | ------------ | --------------------------------- | ----------------------- | | ||
| | v1 | | Feature gate A | | ||
| | v2 | Feature gate A | Feature gate B | |
There was a problem hiding this comment.
Is this purely an example, or are we considering only one version to be able to deploy at a time? It might be helpful to include the number of simultaneous SBPF versions that the network will allow.
There was a problem hiding this comment.
Yes the proposal right now says that there can only be one deployable version at a time (but many executable versions). See the discussion above.
No description provided.