SIMD-0088: Enable Core BPF Programs (#88)

* simd: enable core bpf programs

* address jon initial feedback

* add recent sync feedback

* remove upgrade authority details

* address tyera review feedback

* drop duplicate paragraph

* language suggestions

* add more requirements to migration SIMDs

* explicitly state program IDs are unchanged

* add mention of resource metrics backwards compatibility

* dedupe backward compat paragraph

proposals/0088-enable-core-bpf-programs.md

@@ -0,0 +1,124 @@
+---
+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)
+---
+
+## Summary
+
+This proposal introduces the concept of Core BPF programs: programs which are
+essential to network operations. Currently, these exist as built-in programs
+known as "native" programs.
+
+This SIMD details the process by which existing native programs can be
+ported to Core BPF, as well as the process for introducing brand-new Core BPF
+programs.
+
+## Motivation
+
+BPF programs offer less complexity than native programs 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
+updated once.
+
+For this reason, it makes sense to introduce the concept of Core BPF programs:
+BPF programs the network depends on that should be treated with special care.
+
+## Alternatives Considered
+
+The alternative to Core BPF programs is to keep these essential programs as
+native programs. This would mean each validator client implementation would have
+to build and maintain these built-in programs with their runtime
+implementations, including any future changes to these programs introduced via
+SIMDs or other fixes.
+
+## New Terminology
+
+- `Core BPF Program`: A BPF program relied on by any part of the Solana stack,
+  including (but not limited to) consensus, transaction processing, voting,
+  staking, and account creation.
+
+## Detailed Design
+
+Core BPF programs in many ways will be designed no differently than any other
+BPF program on Solana. However, some programs may require special privileges,
+which is beyond the scope of this SIMD.
+
+When an existing native program is being proposed to be migrated to Core BPF,
+or when a new Core BPF program is being introduced, at least one SIMD shall be
+published outlining at least the following details:
+
+- The interface for the program
+- A precise and complete specification of its behavior
+- How any required special privileges will be granted to the program in its BPF
+  form
+- Whether or not this program will be an upgradeable or non-upgradeable BPF
+  program
+- How this changes to this program will be managed after it becomes BPF
+
+**Migrating a native program to core BPF** shall consist of deploying a
+BPF version of the native program to a new arbitrary address and using a
+feature gate to move the BPF program, replacing the existing native program at
+its original program address. No program IDs for existing native programs would
+be changed by this migration process.
+
+In the context of this design, **target program** refers to an existing native
+program, while **source program** refers to the BPF version to be moved into the
+existing program account.
+
+The migration process must adhere to the following steps:
+
+1. Verifiably build the source BPF program.
+2. Generate a new keypair for the source program.
+3. Deploy the program to the source program address.
+4. Generate a new keypair for the feature gate.
+5. Create a new feature gate to replace the target program with the source BPF
+   program.
+6. Follow the existing process for activating features.
+
+## Impact
+
+With this change, validator clients would no longer be required to implement
+changes to essential programs. Instead these programs could be updated just
+once. This reduces some engineering overhead on validator teams.
+
+## Security Considerations
+
+This proposal establishes the concept of relying on BPF programs that are not
+built into the runtime for essential cluster operations. Depending on how these
+programs are elected to be upgraded, there are some obvious security
+considerations around who can upgrade these programs and when. Any new Core BPF
+program should follow a fully-fledged SIMD process addressing these concerns.
+
+When it comes to migrating native programs to core BPF, this change introduces a
+serious security consideration surrounding the replacement of an essential
+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
+reimplemented incorrectly, or somehow erased during migration, it could have
+immediate and fatal consequences for the network.
+
+## Backwards Compatibility
+
+This proposal itself does not directly introduce any breaking changes. The code
+introduced to migrate native programs to core BPF programs will exist off of the
+runtime's "hot path" until it's actually used for a migration.
+
+When a migration is conducted, the BPF version of a native program will be
+absolutely backwards compatible *functionally*. Its BPF version must provide the
+exact same results as the original native program it aims to replace.
+
+However, since BPF programs cannot precisely match the compute meter and other
+resource limits of their original native counterparts, some of these metrics may
+be slightly different when a native program becomes BPF, thereby affecting
+backwards compatibility in that regard.
+
+Additionally, once a native program has been migrated to core BPF, the process
+by which this program is upgraded will not be backwards compatible. Core
+contributors must follow the upgrade process outlined in each program's
+migration SIMD.