diff --git a/proposals/0088-enable-core-bpf-programs.md b/proposals/0088-enable-core-bpf-programs.md new file mode 100644 index 00000000..7d0f29d3 --- /dev/null +++ b/proposals/0088-enable-core-bpf-programs.md @@ -0,0 +1,171 @@ +--- +simd: '0088' +title: Enable Core BPF Programs +authors: + - Joe Caulfield +category: Standard +type: Core +status: Draft +created: 2023-11-07 +feature: (fill in with feature tracking issues once accepted) +supersedes: '0077' +--- + +## Summary + +### Roadmap + +This is SIMD 1/4 expected for **Multi-Client Feature Gates**. See + + +**Goals:** + +- An official process for upgrading core BPF programs and migrating native + programs to core BPF +- Expanded control over pending feature activations +- Automatic feature activation selection based on stake weight with supporting + software +- Decentralized control over queuing new runtime features + +**Resulting Architecture:** + +1. 👉 **Core BPF Programs:** Enshrined BPF programs responsible for integral + cluster operations, including managing feature gates. +2. **Feature Control:** Features can be created by anyone. Each is owned by the + core BPF Feature Gate program at + `Feature111111111111111111111111111111111111`, which gives core contributors + added control over pending activations. +3. **Feature Recognition & Activation:** Features qualify for activation based + on stake support of nodes who recognize the feature in their software + version. +4. **Feature Queuing:** A governance process nominates eligible features that + should be queued for activation. + +### Proposal + +This SIMD outlines the process by which engineers will manage upgrades to +enshrined Core BPF programs, which are essential to network operations. This +process will also be used to migrate existing native programs to Core BPF +programs. + +## Motivation + +With the advent of Program Runtime v2 and Firedancer, native programs will +eventually become BPF programs. + +Program Runtime v2 will introduce a brand-new ABI for on-chain programs, and the +native programs will need to be revised to support it. + +BPF programs offer less complexity for other clients, such as Firedancer, since +developers will no longer have to keep up with program changes in their runtime +implementations. Instead, the program can just be modified once. + +For these reasons, it makes sense to introduce the concept of Core BPF programs: +BPF programs the network depends on that should be upgraded with a special +process. + +With an explicit process in place for upgrading Core BPF programs, engineers can +safely manage changes to essential programs through feature gates. The feature +gate process requries incremental activations on each cluster: testnet, then +devnet, then mainnet-beta. This is extremely valuable for ensuring a change has +been safely integrated and will not have negative effects on mainnet-beta. + +This same explicit process can be used to migrate existing native programs to +their new Core BPF versions. + +## New Terminology + +- `Core BPF Program`: A **non-upgradeable** BPF program relied on by any part of + the Solana stack, including (but not limited to) consensus, transaction + processing, voting, staking, and account creation. +- `Target Program`: The core program intending to be changed by some + feature activation. +- `Source Program`: The modified version of a core program intending to be moved + in place of the existing core program. + +## Detailed Design + +Core BPF programs shall be non-upgradeable BPF programs deployed with +`BPFLoader2111111111111111111111111111111111`. + +Core BPF programs must only be modified through feature gates. + +**Upgrading a core BPF program** shall consist of deploying the modified program +source code to a new arbitrary address as a **non-upgradeable** BPF program and +creating a feature gate to, using the runtime, move the modified program in +place of the existing program. + +Note, since this deployed program will be deployed using the non-upgradeable BPF +loader (`BPFLoader2111111111111111111111111111111111`), it will consist of only +a program account, with no additional program _data_ account. + +This process must adhere to the following steps: + +1. Verifiably build the modified program. +2. Generate a new keypair for the **source** program. +3. Deploy the program to the **source** address. +4. Generate a new keypair for the **feature gate**. +5. Create a new feature gate for replacing the **target** program with the + **source** (modified) program. +6. Follow the existing process for activating features. + +An additional optional field could be added to feature gate issues for the +**target program** being upgraded. + +**Migrating a native program** to a core BPF program shall consist of following +the exact steps outlined above with the modified BPF version of the program. +This will effectively replace the program at the target address with its core +BPF implementation. + +Some additional checks should be run when doing a migration instead of an +upgrade, such as: + +- Validating the native program's owner is + `NativeLoader1111111111111111111111111111111` +- Ensuring the core BPF program has the correct state + +## Impact + +This proposed change would result in a new process for upgrading core programs. +Although this process will still require feature gates as it does now, the +change is handled completely differently. + +The act of deploying the modified program and using a runtime feature gate to +move it into the proper account will be an entirely new way of upgrading +programs that were previously native. + +Core contributors will have to become comfortable with this process. + +## Security Considerations + +This proposal provides a secure means for upgrading core BPF programs - a +process that will be increasingly valuable as new core BPF programs are created. + +However, this change also introduces a critical security consideration +surrounding the replacement of a core program with the contents of another +account. This is an extremely sensitive process that must be handled with +maximum caution. + +If a core program is modified incorrectly, or somehow erased during migration, +it could have immediate and fatal consequences for the network. + +## Backwards Compatibility + +This feature itself does not directly introduce any breaking changes. + +When this proposed process is used to migrate a native program to core BPF, that +program will be completely backwards compatible. + +However, once a program has been migrated to core BPF, the process by which this +program is upgraded will not be backward compatible. Core contributors must +follow the new process. + +## Alternatives Considered + +An alternative approach to managing upgrades to essential core programs could be +to make these core BPF programs _upgradeable_ and establish a multi-signature +upgrade authority. This authority could be comprised of key-holders from each +validator client: Solana Labs, Jito, Jump, and possibly Syndica (Sig). + +However, this approach adds additional layers of complexity around upgrading +these programs behind a feature-gate.