From 9348ef724ecec7b6ddbcd09f57142ebce9efd90d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alexander=20Mei=C3=9Fner?= Date: Mon, 15 Jul 2024 15:59:26 +0200 Subject: [PATCH 1/5] First draft --- proposals/XXXX-sbpf-feature-gating.md | 70 +++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 proposals/XXXX-sbpf-feature-gating.md diff --git a/proposals/XXXX-sbpf-feature-gating.md b/proposals/XXXX-sbpf-feature-gating.md new file mode 100644 index 00000000..12fa797a --- /dev/null +++ b/proposals/XXXX-sbpf-feature-gating.md @@ -0,0 +1,70 @@ +--- +simd: 'XXXX' +title: Feature Gating for SBPF +authors: + - Alexander Meißner +category: Standard +type: Core +status: Draft +created: 2024-07-15 +--- + +## Summary + +A feature gating and deprecation mechanism for SBPF programs based on their individual program accounts. + +## Motivation + +Over the past three years engineers maintaining the program runtime and virtual machine have identified a list of weaknesses and shortcomings in the SBPF bytecode / ISA, as well as its container format the loading thereof. + +Some of these changes reduce complexity for validator implementations, thereby improving overall performance and reducing attack surface; others enable dapps to use cheaper paths for equivalent computations or remove foot guns for dapp developers. + +Changes were made via global feature activation in cases where the negative impact on already deployed programs was deemed minimal. In a few cases only the deployment of new programs was restricted, while already deployed programs can still be executed. All other cases in which a recompilation with an updated toolchain and subsequent redeployment (both done by the dapp developers / ecosystem) are necessary were put on hold. So far, these have been accumulated under the term SBPF-v2. + +However, to facilitate a more streamlined rollout and testing it is likely beneficial to split up SBPF-v2 into multiple smaller releases. + +## New Terminology + +None. + +## Detailed Design + +Every program must signal which change set it was compiled for via the `e_flags` field in the [ELF header](https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html). Thus, the feature gating would not be runtime global, and not be based on the loader, but on every program individually. The `e_flags` field is effectively a toolchain compatibility version number as each change set will be a superset of all changes that came before. In order to prevent an "extension hell" it is not possible to opt into specific changes, instead the entire change set is reduced to a single SBPF version number. + +Block explorers are recommended to display the SBPF version field for program accounts. + +Based on this SBPF version field a validator implementation must load and execute each individual program differently according to the SBPF version it requires. Introduction feature gates (one for each SBPF version) control the allowed re/deployed and execution of programs. Upon activation of an introduction feature gate for a new SBPF version programs compiled for: +- any earlier SBPF version must be rejected by the loader (can not be re/deployed anymore) +- exactly the SBPF version must be accepted by the loader (can now be re/deployed) +- any earlier SBPF version must be executed (can still be executed) +- exactly the SBPF version must be executed (can now be executed) + +Deprecation feature gates control program execution and fees thereof (CU costs). Instead of having each version be deprecated individually these would happen in larger blocks composed of multiple version numbers to reduce the amount of redeployment required from dapp develpers. In order to avoid a "rugpull" like surprise for users of programs which depend on a versions that are about to be deprecated a linear "ramp up" in CU costs must commence at feature activation and finally end in the denial of execution at a fixed slot offset after the feature activation. + +## Alternatives Considered + +### Use the runtime global feature gating mechanism +This would mean all programs need to be redeployed simultaneously at feature activation and that they would each require an alternative version to be prepared and uploaded to be switched to (redeployed) on feature activation. This would increase the complexity of program management in loaders and require dapp developers to double the locked tokens in their deployed programs. + +It also means that validator implementations would have to handle a massive ammount of loading, parsing, relocation, verification and possibly compilation of programs in a single block. It took the Agave team two years to develop, implement, test and deploy this capability. It is desireable for other validator implementations to avoid having to do the same. + +### Coupling the feature gating to the loader, not the individual program accounts +The version number could be impled by the loader a program was deployed in, effectively shifting the encoding from the program account content to the owner field. This would require a new loader address for each SBPF version, as the program management and execution logic could be shared for the most part. However, new loaders would necessitate a way to migrate programs between loaders upon redeployment. + +## Impact + +Active dapp developers who redeploy their programs regularly will (upon feature activation) be forced to also keep their toolchain up-to-date, which they most likely do anyway. + +Less active dapp developers who do not redeploy their programs will be nagged 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 userbase slowly migrate their funds to alternative programs. + +Validator implementations will have to support multiple code paths in the time between the introduction feature activation and the fixed slot offset after the deprecation feature activation. + +## Security Considerations + +None. + +## Drawbacks + +Programs will break and if they are finalized their addresses and deployment cost will be burnt. From b385d75989a354f892c6e553242e80b4caf95a95 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alexander=20Mei=C3=9Fner?= Date: Wed, 17 Jul 2024 13:29:59 +0200 Subject: [PATCH 2/5] Fixes typos --- proposals/XXXX-sbpf-feature-gating.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/XXXX-sbpf-feature-gating.md b/proposals/XXXX-sbpf-feature-gating.md index 12fa797a..1d822369 100644 --- a/proposals/XXXX-sbpf-feature-gating.md +++ b/proposals/XXXX-sbpf-feature-gating.md @@ -39,17 +39,17 @@ Based on this SBPF version field a validator implementation must load and execut - any earlier SBPF version must be executed (can still be executed) - exactly the SBPF version must be executed (can now be executed) -Deprecation feature gates control program execution and fees thereof (CU costs). Instead of having each version be deprecated individually these would happen in larger blocks composed of multiple version numbers to reduce the amount of redeployment required from dapp develpers. In order to avoid a "rugpull" like surprise for users of programs which depend on a versions that are about to be deprecated a linear "ramp up" in CU costs must commence at feature activation and finally end in the denial of execution at a fixed slot offset after the feature activation. +Deprecation feature gates control program execution and fees thereof (CU costs). Instead of having each version be deprecated individually these would happen in larger blocks composed of multiple version numbers to reduce the amount of redeployment required from dapp developers. In order to avoid a "rugpull" like surprise for users of programs which depend on a versions that are about to be deprecated a linear "ramp up" in CU costs must commence at feature activation and finally end in the denial of execution at a fixed slot offset after the feature activation. ## Alternatives Considered ### Use the runtime global feature gating mechanism This would mean all programs need to be redeployed simultaneously at feature activation and that they would each require an alternative version to be prepared and uploaded to be switched to (redeployed) on feature activation. This would increase the complexity of program management in loaders and require dapp developers to double the locked tokens in their deployed programs. -It also means that validator implementations would have to handle a massive ammount of loading, parsing, relocation, verification and possibly compilation of programs in a single block. It took the Agave team two years to develop, implement, test and deploy this capability. It is desireable for other validator implementations to avoid having to do the same. +It also means that validator implementations would have to handle a massive amount of loading, parsing, relocation, verification and possibly compilation of programs in a single block. It took the Agave team two years to develop, implement, test and deploy this capability. It is desirable for other validator implementations to avoid having to do the same. ### Coupling the feature gating to the loader, not the individual program accounts -The version number could be impled by the loader a program was deployed in, effectively shifting the encoding from the program account content to the owner field. This would require a new loader address for each SBPF version, as the program management and execution logic could be shared for the most part. However, new loaders would necessitate a way to migrate programs between loaders upon redeployment. +The version number could be implied by the loader a program was deployed in, effectively shifting the encoding from the program account content to the owner field. This would require a new loader address for each SBPF version, as the program management and execution logic could be shared for the most part. However, new loaders would necessitate a way to migrate programs between loaders upon redeployment. ## Impact @@ -57,7 +57,7 @@ Active dapp developers who redeploy their programs regularly will (upon feature Less active dapp developers who do not redeploy their programs will be nagged 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 userbase slowly migrate their funds to alternative programs. +Finalized programs which simply can not be redeployed will instead have their user base slowly migrate their funds to alternative programs. Validator implementations will have to support multiple code paths in the time between the introduction feature activation and the fixed slot offset after the deprecation feature activation. From fcf1694cd9c6800c08264d492ff9ca4ae7c25325 Mon Sep 17 00:00:00 2001 From: Alessandro Decina Date: Thu, 25 Jul 2024 00:23:16 +0700 Subject: [PATCH 3/5] tmp --- proposals/XXXX-sbpf-feature-gating.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/proposals/XXXX-sbpf-feature-gating.md b/proposals/XXXX-sbpf-feature-gating.md index 1d822369..bca23918 100644 --- a/proposals/XXXX-sbpf-feature-gating.md +++ b/proposals/XXXX-sbpf-feature-gating.md @@ -1,6 +1,6 @@ --- simd: 'XXXX' -title: Feature Gating for SBPF +title: Explicit versioning and feature gating of SBPF programs authors: - Alexander Meißner category: Standard @@ -11,25 +11,25 @@ created: 2024-07-15 ## Summary -A feature gating and deprecation mechanism for SBPF programs based on their individual program accounts. +An explicit versioning system for SBPF programs, that allows enabling or disabling features on a per-program basis. ## Motivation -Over the past three years engineers maintaining the program runtime and virtual machine have identified a list of weaknesses and shortcomings in the SBPF bytecode / ISA, as well as its container format the loading thereof. +SBPF has evolved over the years and will continue to evolve. Changes are necessary among other reasons to improve performance, address security concerns and provide new, better features to dapp developers. -Some of these changes reduce complexity for validator implementations, thereby improving overall performance and reducing attack surface; others enable dapps to use cheaper paths for equivalent computations or remove foot guns for 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 feature gates in the past to restrict new deployments of programs owned by deprecated loaders. Feature gates alone are not sufficient to evolve SBPF though - we are missing a mechanism to enable (or disable) specific features on a per-program basis. -Changes were made via global feature activation in cases where the negative impact on already deployed programs was deemed minimal. In a few cases only the deployment of new programs was restricted, while already deployed programs can still be executed. All other cases in which a recompilation with an updated toolchain and subsequent redeployment (both done by the dapp developers / ecosystem) are necessary were put on hold. So far, these have been accumulated under the term SBPF-v2. +As an example, over two years ago we decided to change the way the stack works for SBPF programs - from allocating a fixed 4kB per function frame, to letting functions dynamically specify how much stack they need. This change was implemented in both the program runtime and the toolchain (LLVM), but as of today it has not yet been deployed, because it's essentially too hard to do so: upon executing a program, should the program runtime use the old or the new stack allocation strategy? -However, to facilitate a more streamlined rollout and testing it is likely beneficial to split up SBPF-v2 into multiple smaller releases. +We propose to introduce an explicit versioning scheme for SBPF programs: programs will encode which SBPF version they are compiled for; based on this version, the program runtime will alter its behavior. ## New Terminology -None. +SBPF version: the SBPF version number a program was compiled for. ## Detailed Design -Every program must signal which change set it was compiled for via the `e_flags` field in the [ELF header](https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html). Thus, the feature gating would not be runtime global, and not be based on the loader, but on every program individually. The `e_flags` field is effectively a toolchain compatibility version number as each change set will be a superset of all changes that came before. In order to prevent an "extension hell" it is not possible to opt into specific changes, instead the entire change set is reduced to a single SBPF version number. +Every program must signal which SBPF version it was compiled for via the `e_flags` field in the [ELF header](https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html). Thus, the feature gating would not be runtime global, and not be based on the loader, but on every program individually. The `e_flags` field is effectively a toolchain compatibility version number as each change set will be a superset !!!NOT correct, eg dynamic frames is not a superset!!! of all changes that came before. In order to prevent an "extension hell" it is not possible to opt into specific changes, instead the entire change set is reduced to a single SBPF version number. Block explorers are recommended to display the SBPF version field for program accounts. From 47563bd0c560bd0df8f04ad5746a8ffaedef8bbd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alexander=20Mei=C3=9Fner?= Date: Thu, 25 Jul 2024 10:43:39 +0200 Subject: [PATCH 4/5] Simplifies "Detailed Design" section and adds an example. --- proposals/XXXX-sbpf-feature-gating.md | 30 ++++++++++++++++----------- 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/proposals/XXXX-sbpf-feature-gating.md b/proposals/XXXX-sbpf-feature-gating.md index bca23918..d318a741 100644 --- a/proposals/XXXX-sbpf-feature-gating.md +++ b/proposals/XXXX-sbpf-feature-gating.md @@ -3,6 +3,7 @@ simd: 'XXXX' title: Explicit versioning and feature gating of SBPF programs authors: - Alexander Meißner + - Alessandro Decina category: Standard type: Core status: Draft @@ -21,7 +22,7 @@ Today, the only way to introduce changes to the program runtime is via feature g As an example, over two years ago we decided to change the way the stack works for SBPF programs - from allocating a fixed 4kB per function frame, to letting functions dynamically specify how much stack they need. This change was implemented in both the program runtime and the toolchain (LLVM), but as of today it has not yet been deployed, because it's essentially too hard to do so: upon executing a program, should the program runtime use the old or the new stack allocation strategy? -We propose to introduce an explicit versioning scheme for SBPF programs: programs will encode which SBPF version they are compiled for; based on this version, the program runtime will alter its behavior. +We propose to introduce an explicit versioning scheme for SBPF programs: programs will encode which SBPF version they are compiled for; based on this version, the program runtime will alter its behavior. In order to prevent an "extension hell" it will not be possible to opt into specific changes via flags, instead an entire set of changes is reduced to a single SBPF version. ## New Terminology @@ -29,17 +30,22 @@ SBPF version: the SBPF version number a program was compiled for. ## Detailed Design -Every program must signal which SBPF version it was compiled for via the `e_flags` field in the [ELF header](https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html). Thus, the feature gating would not be runtime global, and not be based on the loader, but on every program individually. The `e_flags` field is effectively a toolchain compatibility version number as each change set will be a superset !!!NOT correct, eg dynamic frames is not a superset!!! of all changes that came before. In order to prevent an "extension hell" it is not possible to opt into specific changes, instead the entire change set is reduced to a single SBPF version number. - -Block explorers are recommended to display the SBPF version field for program accounts. - -Based on this SBPF version field a validator implementation must load and execute each individual program differently according to the SBPF version it requires. Introduction feature gates (one for each SBPF version) control the allowed re/deployed and execution of programs. Upon activation of an introduction feature gate for a new SBPF version programs compiled for: -- any earlier SBPF version must be rejected by the loader (can not be re/deployed anymore) -- exactly the SBPF version must be accepted by the loader (can now be re/deployed) -- any earlier SBPF version must be executed (can still be executed) -- exactly the SBPF version must be executed (can now be executed) - -Deprecation feature gates control program execution and fees thereof (CU costs). Instead of having each version be deprecated individually these would happen in larger blocks composed of multiple version numbers to reduce the amount of redeployment required from dapp developers. In order to avoid a "rugpull" like surprise for users of programs which depend on a versions that are about to be deprecated a linear "ramp up" in CU costs must commence at feature activation and finally end in the denial of execution at a fixed slot offset after the feature activation. +Every program must signal which SBPF version it was compiled for via the `e_flags` field in the [ELF header](https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html). Block explorers are recommended to display this SBPF version field for program accounts. + +For each SBPF version two feature gates will control its availability: +- One to enable deployment and execution of that SBPF version, which includes disabling deployment (but not execution) of all earlier versions. +- 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. + +#### Example +| SBPF version | becomes deployable and executable | ceases to be deployable | ceases to be executable | +| ------------ | --------------------------------- | ----------------------- | ----------------------- | +| v1 | | Feature gate A | Feature gate G | +| v2 | Feature gate A | Feature gate B | Feature gate G | +| v3 | Feature gate B | Feature gate C | Feature gate G | +| v4 | Feature gate C | Feature gate D | Feature gate H | +| v5 | Feature gate D | Feature gate E | Feature gate H | +| v6 | Feature gate E | Feature gate F | Feature gate H | +| v7 | Feature gate F | | | ## Alternatives Considered From ab8e75a25e6dece495bfe2a2b974a1e48a8f6598 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alexander=20Mei=C3=9Fner?= Date: Fri, 26 Jul 2024 14:36:19 +0200 Subject: [PATCH 5/5] Makes CI happy. --- proposals/0161-sbpf-feature-gating.md | 138 ++++++++++++++++++++++++++ proposals/XXXX-sbpf-feature-gating.md | 76 -------------- 2 files changed, 138 insertions(+), 76 deletions(-) create mode 100644 proposals/0161-sbpf-feature-gating.md delete mode 100644 proposals/XXXX-sbpf-feature-gating.md diff --git a/proposals/0161-sbpf-feature-gating.md b/proposals/0161-sbpf-feature-gating.md new file mode 100644 index 00000000..c97559f1 --- /dev/null +++ b/proposals/0161-sbpf-feature-gating.md @@ -0,0 +1,138 @@ +--- +simd: '0161' +title: SBPF versioning and feature gating +authors: + - Alexander Meißner + - Alessandro Decina +category: Standard +type: Core +status: Draft +created: 2024-07-15 +--- + +## Summary + +An explicit versioning system for SBPF programs, that allows enabling or +disabling features on a per-program basis. + +## Motivation + +SBPF has evolved over the years and will continue to evolve. Changes are +necessary among other reasons to improve performance, address security concerns +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 +feature gates in the past to restrict new deployments of programs owned by +deprecated loaders. Feature gates alone are not sufficient to evolve SBPF +though - we are missing a mechanism to enable (or disable) specific features on +a per-program basis. + +As an example, over two years ago we decided to change the way the stack works +for SBPF programs - from allocating a fixed 4kB per function frame, to letting +functions dynamically specify how much stack they need. This change was +implemented in both the program runtime and the toolchain (LLVM), but as of +today it has not yet been deployed, because it's essentially too hard to do so: +upon executing a program, should the program runtime use the old or the new +stack allocation strategy? + +We propose to introduce an explicit versioning scheme for SBPF programs: +programs will encode which SBPF version they are compiled for; based on this +version, the program runtime will alter its behavior. In order to prevent an +"extension hell" it will not be possible to opt into specific changes via +flags, instead an entire set of changes is reduced to a single SBPF version. + +## New Terminology + +SBPF version: the SBPF version number a program was compiled for. + +## Detailed Design + +Every program must signal which SBPF version it was compiled for via +the `e_flags` field in the +[ELF header](https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html). +Block explorers are recommended to display this SBPF version field for program +accounts. + +For each SBPF version two feature gates will control its availability: + +- One to enable deployment and execution of that SBPF version, which includes +disabling deployment (but not execution) of all earlier versions. +- 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. + +### Example + +| SBPF version | becomes deployable and executable | ceases to be deployable | +| ------------ | --------------------------------- | ----------------------- | +| v1 | | Feature gate A | +| v2 | Feature gate A | Feature gate B | +| v3 | Feature gate B | Feature gate C | +| v4 | Feature gate C | Feature gate D | +| v5 | Feature gate D | Feature gate E | +| v6 | Feature gate E | Feature gate F | +| v7 | Feature gate F | | + +| SBPF version | ceases to be executable | +| ------------ | ----------------------- | +| v1 | Feature gate G | +| v2 | Feature gate G | +| v3 | Feature gate G | +| v4 | Feature gate H | +| v5 | Feature gate H | +| v6 | Feature gate H | +| v7 | | + +## Alternatives Considered + +### Use the runtime global feature gating mechanism + +This would mean all programs need to be redeployed simultaneously at feature +activation and that they would each require an alternative version to be +prepared and uploaded to be switched to (redeployed) on feature activation. +This would increase the complexity of program management in loaders and require +dapp developers to double the locked tokens in their deployed programs. + +It also means that validator implementations would have to handle a massive +amount of loading, parsing, relocation, verification and possibly compilation +of programs in a single block. It took the Agave team two years to develop, +implement, test and deploy this capability. It is desirable for other validator +implementations to avoid having to do the same. + +### Coupling the feature gating to the loader, not the individual program accounts + +The version number could be implied by the loader a program was deployed in, +effectively shifting the encoding from the program account content to the owner +field. This would require a new loader address for each SBPF version, as the +program management and execution logic could be shared for the most part. +However, new loaders would necessitate a way to migrate programs between +loaders upon redeployment. + +## Impact + +Active dapp developers who redeploy their programs regularly will (upon feature +activation) be forced to also keep their toolchain up-to-date, which they most +likely do anyway. + +Less active dapp developers who do not redeploy their programs will be nagged +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 +user base slowly migrate their funds to alternative programs. + +Validator implementations will have to support multiple code paths in the time +between the introduction feature activation and the fixed slot offset after the +deprecation feature activation. + +## Security Considerations + +None. + +## Drawbacks + +Programs will break and if they are finalized their addresses and deployment +cost will be burnt. diff --git a/proposals/XXXX-sbpf-feature-gating.md b/proposals/XXXX-sbpf-feature-gating.md deleted file mode 100644 index d318a741..00000000 --- a/proposals/XXXX-sbpf-feature-gating.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -simd: 'XXXX' -title: Explicit versioning and feature gating of SBPF programs -authors: - - Alexander Meißner - - Alessandro Decina -category: Standard -type: Core -status: Draft -created: 2024-07-15 ---- - -## Summary - -An explicit versioning system for SBPF programs, that allows enabling or disabling features on a per-program basis. - -## Motivation - -SBPF has evolved over the years and will continue to evolve. Changes are necessary among other reasons to improve performance, address security concerns 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 feature gates in the past to restrict new deployments of programs owned by deprecated loaders. Feature gates alone are not sufficient to evolve SBPF though - we are missing a mechanism to enable (or disable) specific features on a per-program basis. - -As an example, over two years ago we decided to change the way the stack works for SBPF programs - from allocating a fixed 4kB per function frame, to letting functions dynamically specify how much stack they need. This change was implemented in both the program runtime and the toolchain (LLVM), but as of today it has not yet been deployed, because it's essentially too hard to do so: upon executing a program, should the program runtime use the old or the new stack allocation strategy? - -We propose to introduce an explicit versioning scheme for SBPF programs: programs will encode which SBPF version they are compiled for; based on this version, the program runtime will alter its behavior. In order to prevent an "extension hell" it will not be possible to opt into specific changes via flags, instead an entire set of changes is reduced to a single SBPF version. - -## New Terminology - -SBPF version: the SBPF version number a program was compiled for. - -## Detailed Design - -Every program must signal which SBPF version it was compiled for via the `e_flags` field in the [ELF header](https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html). Block explorers are recommended to display this SBPF version field for program accounts. - -For each SBPF version two feature gates will control its availability: -- One to enable deployment and execution of that SBPF version, which includes disabling deployment (but not execution) of all earlier versions. -- 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. - -#### Example -| SBPF version | becomes deployable and executable | ceases to be deployable | ceases to be executable | -| ------------ | --------------------------------- | ----------------------- | ----------------------- | -| v1 | | Feature gate A | Feature gate G | -| v2 | Feature gate A | Feature gate B | Feature gate G | -| v3 | Feature gate B | Feature gate C | Feature gate G | -| v4 | Feature gate C | Feature gate D | Feature gate H | -| v5 | Feature gate D | Feature gate E | Feature gate H | -| v6 | Feature gate E | Feature gate F | Feature gate H | -| v7 | Feature gate F | | | - -## Alternatives Considered - -### Use the runtime global feature gating mechanism -This would mean all programs need to be redeployed simultaneously at feature activation and that they would each require an alternative version to be prepared and uploaded to be switched to (redeployed) on feature activation. This would increase the complexity of program management in loaders and require dapp developers to double the locked tokens in their deployed programs. - -It also means that validator implementations would have to handle a massive amount of loading, parsing, relocation, verification and possibly compilation of programs in a single block. It took the Agave team two years to develop, implement, test and deploy this capability. It is desirable for other validator implementations to avoid having to do the same. - -### Coupling the feature gating to the loader, not the individual program accounts -The version number could be implied by the loader a program was deployed in, effectively shifting the encoding from the program account content to the owner field. This would require a new loader address for each SBPF version, as the program management and execution logic could be shared for the most part. However, new loaders would necessitate a way to migrate programs between loaders upon redeployment. - -## Impact - -Active dapp developers who redeploy their programs regularly will (upon feature activation) be forced to also keep their toolchain up-to-date, which they most likely do anyway. - -Less active dapp developers who do not redeploy their programs will be nagged 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 user base slowly migrate their funds to alternative programs. - -Validator implementations will have to support multiple code paths in the time between the introduction feature activation and the fixed slot offset after the deprecation feature activation. - -## Security Considerations - -None. - -## Drawbacks - -Programs will break and if they are finalized their addresses and deployment cost will be burnt.