address jon initial feedback

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

@@ -12,70 +12,72 @@ feature: (fill in with feature tracking issues once accepted)
 
 ## Summary
 
-This proposal introduces the concept of Core BPF programs: programs which are
+This proposal outlines the process by which engineers will manage upgrades to
+enshrined Core BPF programs, as well as migrate existing native programs to core
+BPF.
+
+This SIMD also introduces the concept of Core BPF programs: programs which are
 essential to network operations. Currently, these are embedded programs known as
 "native" programs.
 
-This SIMD also outlines the processes by which engineers will manage upgrades to
-these enshrined Core BPF programs, as well as migrate existing native programs
-to core BPF.
-
-## Motivation
+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.
 
-With the advent of Program Runtime v2 and Firedancer, native programs will
-eventually become BPF programs.
+This same explicit process can be used to migrate existing native programs to
+their new Core BPF versions.
 
-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.
+## Motivation
 
 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:
+For this reason, 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.
-
 ## Alternatives Considered
 
-An alternative approach to managing upgrades to essential core programs could be
+An alternative approach to managing upgrades to Core BPF 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.
+Gating upgrades behind a feature-gate has numerous benefits, including a long
+lead time to deployment and requiring validators to upgrade their software to
+signal their acceptance of the change. Allowing Core BPF programs to be upgraded
+by a multi-sig without feature-gating strips core contributors of these
+benefits.
+
+It's possible that multi-sig program upgrades could be combined with
+feature-gates, however this implementation would add additional layers of
+complexity to the upgrade process.
 
 ## 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
 
+In the context of this design, **source program** shall be the modified version
+of a core BPF program intending to be moved in place of the existing program,
+while **target program** is that existing program.
+
 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. 
+to a new arbitrary address as a **non-upgradeable** BPF program and using a
+feature gate to move the modified program in place of the existing program. The
+feature gate is required to circumvent normal transaction processing rules and
+replace the contents of one account with another directly at the runtime level.
 
 Note, since this deployed program will be deployed using the non-upgradeable BPF
 loader (`BPFLoader2111111111111111111111111111111111`), it will consist of only
@@ -100,11 +102,8 @@ 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
+upgrade, such as validating the native program's owner is
+`NativeLoader1111111111111111111111111111111`.
 
 ## Impact
 
@@ -116,8 +115,6 @@ 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
@@ -133,11 +130,14 @@ it could have immediate and fatal consequences for the network.
 
 ## Backwards Compatibility
 
-This feature itself does not directly introduce any breaking changes.
+This proposal itself does not directly introduce any breaking changes. The code
+introduced to migrate native programs or upgrade core BPF programs will exist
+off the runtime's "hot path" until it's actually used for a migration/upgrade.
 
-When this proposed process is used to migrate a native program to core BPF, that
-program will be completely backwards compatible.
+When the mechanism is used _specifically_ to migrate a native program to core
+BPF, the core BPF version will be more than backwards compatible. It must
+provide the exact same results as the native program it aims to replace.
 
 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
+program is upgraded will not be backwards compatible. Core contributors must
 follow the new process.