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.
There was a problem hiding this comment.
I agree that we shouldn't force re-deployments. Mandating that when you do deploy, you can only deploy the latest SBPF version is a reasonable tradeoff between usability and actually getting new versions adopted.
| | 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.
Lichtso
force-pushed
the
sbpf-feature-gating
branch
from
acc594c to
0cc74f8
Compare
| - Another to first disincentivize (via CU costs) and later disable execution | ||
| of that SBPF version, so that the runtime and virtual machine can reduce their | ||
| complexity again. This feature gate can be shared by multiple SBPF versions, | ||
| effectively deprecating larger blocks of versions in order to reduce the amount | ||
| of redeployment required from dapp developers. |
There was a problem hiding this comment.
I'm confused by the word "later" - are we suggesting that the semantics of the feature gate will change over time? Or will there be one feature gate for disincentivization and another for disabling deployment?
| 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 agree that we shouldn't force re-deployments. Mandating that when you do deploy, you can only deploy the latest SBPF version is a reasonable tradeoff between usability and actually getting new versions adopted.
| ### Version discriminator | ||
|
|
||
| Currently the protocol deems every value of `e_flags` which is not `0x0020` as | ||
| being SBPF v0 and thus valid. This clearly does not scale for multiple versions | ||
| and must therefore be changed. With the activation of the first feature gate | ||
| which enables the deployment and execution of the first new SBPF version the | ||
| discriminator must switch to directly interpret `e_flags` as SBPF version. |
There was a problem hiding this comment.
Can we describe exactly how to parse and interpret this field?
There was a problem hiding this comment.
Added a line to describe that via example.
| and provide new, better features to dapp developers. | ||
|
|
||
| Today, the only way to introduce changes to the program runtime is via feature | ||
| gates [link that explains what feature gates are]. For example we have used |
|
|
||
| ## Summary | ||
|
|
||
| An explicit versioning system for SBPF programs, that allows enabling or |
There was a problem hiding this comment.
| An explicit versioning system for SBPF programs, that allows enabling or | |
| An explicit versioning system for SBPF programs, which allows enabling or |
| by their users to redeploy their programs once the deprecation CU cost ramps | ||
| up. | ||
|
|
||
| Finalized programs which simply can not be redeployed will instead have their |
There was a problem hiding this comment.
| Finalized programs which simply can not be redeployed will instead have their | |
| Finalized programs that simply can not be redeployed will instead have their |
No description provided.