From aa16c8d77051e0b376fce9e038c281a06583d89b Mon Sep 17 00:00:00 2001 From: Joe Date: Fri, 10 Nov 2023 14:55:20 +0000 Subject: [PATCH] remove implementation-specific bits --- proposals/enable-core-bpf-programs.md | 30 +++------------------------ 1 file changed, 3 insertions(+), 27 deletions(-) diff --git a/proposals/enable-core-bpf-programs.md b/proposals/enable-core-bpf-programs.md index 53f1a635c..4ed9b65f8 100644 --- a/proposals/enable-core-bpf-programs.md +++ b/proposals/enable-core-bpf-programs.md @@ -115,33 +115,9 @@ This process must adhere to the following steps: An additional optional field could be added to feature gate issues for the **target program** being upgraded. -The necessary code to perform a feature-gated core program upgrade shall be -entirely contained within a single function, stemming from a helper module used -by the bank. - -This function shall: - -- Be specific to only replacing **non-upgradeable** BPF programs with - **non-upgradeable** BPF programs -- Ensure maximally safe usage in feature gates - - Including, but not limited to, guarding against mistaken parameters -- Have extensive test coverage within the runtime source code - - -Here is an example of such a function: - -```rust -enum TargetProgram { - System, - Stake, - Vote, - /* ... */ -} - -fn upgrade_core_program(target_program: TargetProgram, source: Pubkey) { - /* replacement logic */ -} -``` +A hard-coded list of all supported core BPF programs should be used to conduct +all migrations or upgrades with the above outlined process. This provides an +additional for explicitly denoting which program is the target. Migrating a native program to a core BPF program shall use much of the same functionality described above, with added checks specific to native programs,