chore: update Solana docs and code comments that specify "BPF" to "SBF"

cli/src/program.rs

@@ -1398,7 +1398,7 @@ fn process_show(
                     .into())
                 }
             } else {
-                Err(format!("{} is not a BPF program", account_pubkey).into())
+                Err(format!("{} is not an SBF program", account_pubkey).into())
             }
         } else {
             Err(format!("Unable to find the account {}", account_pubkey).into())
@@ -1468,7 +1468,7 @@ fn process_dump(
                     .into())
                 }
             } else {
-                Err(format!("{} is not a BPF program", account_pubkey).into())
+                Err(format!("{} is not an SBF program", account_pubkey).into())
             }
         } else {
             Err(format!("Unable to find the account {}", account_pubkey).into())

core/src/qos_service.rs

@@ -392,7 +392,7 @@ struct QosServiceMetricsStats {
     /// accumulated estimated builtin programs Compute Units to be packed into block
     estimated_builtins_execute_cu: AtomicU64,
 
-    /// accumulated estimated BPF program Compute Units to be packed into block
+    /// accumulated estimated SBF program Compute Units to be packed into block
     estimated_bpf_execute_cu: AtomicU64,
 
     /// accumulated actual program Compute Units that have been packed into block

docs/art/sdk-tools.bob

@@ -3,7 +3,7 @@
                  | Solana Runtime                      |
                  |                                     |
   .----------.   |   .------------.   .------------.   |
-  | Program  |   |   | BPF        |   | Executable |   |
+  | Program  |   |   | SBF        |   | Executable |   |
   | Author   +------>| Bytecode   +-->| Account    |   |
   |          |   |   | Verifier   |   |            |   |
   `----------`   |   `------------`   `------------`   |
@@ -12,7 +12,7 @@
                  |          |  LoadAccounts            |
                  |          V                          |
   .----------.   |   .------------.   .-------------.  |
-  |          |   |   |  BPF       |   | BPF         |  |
+  |          |   |   |  SBF       |   | SBF         |  |
   |  Client  +------>|  Loader    +-->| Interpreter |  |
   |          |   |   |            |   |             |  |
   `----------`   |   `------------`   `-------------`  |

docs/src/cluster/bench-tps.md

@@ -99,7 +99,7 @@ For example
   export RUST_LOG=solana=info,solana::banking_stage=debug
   ```
 
-- To enable BPF program logging:
+- To enable SBF program logging:
 
   ```bash
   export RUST_LOG=solana_bpf_loader=trace

docs/src/developing/backwards-compatibility.md

@@ -24,7 +24,7 @@ and so this document attempts to clarify and codify the process for new releases
 
 ### Release Cadence
 
-The Solana RPC API, Rust SDK, CLI tooling, and BPF Program SDK are all updated and shipped
+The Solana RPC API, Rust SDK, CLI tooling, and SBF Program SDK are all updated and shipped
 along with each Solana software release and should always be compatible between `PATCH`
 updates of a particular `MINOR` version release.
 

docs/src/developing/clients/jsonrpc-api.md

@@ -4160,7 +4160,7 @@ Example:
         "signature": "5h6xBEauJ3PK6SWCZ1PGjBvj8vDdWG3KpwATGy1ARAXFSDwt8GFXM7W5Ncn16wmqokgpiKRLuS83KUxyZyv2sUYv",
         "err": null,
         "logs": [
-          "BPF program 83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri success"
+          "SBF program 83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri success"
         ]
       }
     },

docs/src/developing/clients/rust-api.md

@@ -11,7 +11,7 @@ Solana's Rust crates are [published to crates.io][crates.io] and can be found
 Some important crates:
 
 - [`solana-program`] — Imported by programs running on Solana, compiled
-  to BPF. This crate contains many fundamental data types and is re-exported from
+  to SBF. This crate contains many fundamental data types and is re-exported from
   [`solana-sdk`], which cannot be imported from a Solana program.
 
 - [`solana-sdk`] — The basic off-chain SDK, it re-exports

docs/src/developing/intro/programs.md

@@ -14,7 +14,7 @@ Both types of programs run on top of the [Sealevel runtime](https://medium.com/s
 - Programs can own other Accounts
 - Programs can only _change the data_ or _debit_ accounts they own
 - Any program can _read_ or _credit_ another account
-- Programs are considered stateless since the primary data stored in a program account is the compiled BPF code
+- Programs are considered stateless since the primary data stored in a program account is the compiled SBF code
 - Programs can be upgraded by their owner (see more on that below)
 
 ## Types of programs

docs/src/developing/on-chain-programs/debugging.md

@@ -43,15 +43,15 @@ limited but there are many points of possible failures. The following are
 possible failure points and information about what errors to expect and where to
 get more information:
 
-- The BPF loader may fail to parse the program, this should not happen since the
+- The SBF loader may fail to parse the program, this should not happen since the
   loader has already _finalized_ the program's account data.
   - `InstructionError::InvalidAccountData` will be returned as part of the
     transaction error.
-- The BPF loader may fail to setup the program's execution environment
+- The SBF loader may fail to setup the program's execution environment
   - `InstructionError::Custom(0x0b9f_0001)` will be returned as part of the
     transaction error. "0x0b9f_0001" is the hexadecimal representation of
     [`VirtualMachineCreationFailed`](https://github.com/solana-labs/solana/blob/bc7133d7526a041d1aaee807b80922baa89b6f90/programs/bpf_loader/src/lib.rs#L44).
-- The BPF loader may have detected a fatal error during program executions
+- The SBF loader may have detected a fatal error during program executions
   (things like panics, memory violations, system call errors, etc...)
   - `InstructionError::Custom(0x0b9f_0002)` will be returned as part of the
     transaction error. "0x0b9f_0002" is the hexadecimal representation of
@@ -71,7 +71,7 @@ logs](debugging.md#logging).
 For example, an access violation involving the stack will look something like
 this:
 
-`BPF program 4uQeVj5tqViQh7yWWGStvkEG1Zmhx6uasJtWCJziofM failed: out of bounds memory store (insn #615), addr 0x200001e38/8`
+`SBF program 4uQeVj5tqViQh7yWWGStvkEG1Zmhx6uasJtWCJziofM failed: out of bounds memory store (insn #615), addr 0x200001e38/8`
 
 ## Monitoring Compute Budget Consumption
 
@@ -89,22 +89,22 @@ for more information.
 
 ## ELF Dump
 
-The BPF shared object internals can be dumped to a text file to gain more
+The SBF shared object internals can be dumped to a text file to gain more
 insight into a program's composition and what it may be doing at runtime.
 
 - [Create a dump file of a Rust program](developing-rust.md#elf-dump)
 - [Create a dump file of a C program](developing-c.md#elf-dump)
 
 ## Instruction Tracing
 
-During execution the runtime BPF interpreter can be configured to log a trace
-message for each BPF instruction executed. This can be very helpful for things
+During execution the runtime SBF interpreter can be configured to log a trace
+message for each SBF instruction executed. This can be very helpful for things
 like pin-pointing the runtime context leading up to a memory access violation.
 
 The trace logs together with the [ELF dump](#elf-dump) can provide a lot of
 insight (though the traces produce a lot of information).
 
-To turn on BPF interpreter trace messages in a local cluster configure the
+To turn on SBF interpreter trace messages in a local cluster configure the
 `solana_rbpf` level in `RUST_LOG` to `trace`. For example:
 
 `export RUST_LOG=solana_rbpf=trace`

docs/src/developing/on-chain-programs/deploying.md

@@ -5,7 +5,7 @@ title: "Deploying Programs"
 ![SDK tools](/img/sdk-tools.svg)
 
 As shown in the diagram above, a program author creates a program, compiles it
-to an ELF shared object containing BPF bytecode, and uploads it to the Solana
+to an ELF shared object containing SBF bytecode, and uploads it to the Solana
 cluster with a special _deploy_ transaction. The cluster makes it available to
 clients via a _program ID_. The program ID is an _address_ specified when
 deploying and is used to reference the program in subsequent transactions.

docs/src/developing/on-chain-programs/developing-rust.md

@@ -39,14 +39,14 @@ using the `no-entrypoint` feature.
 At a minimum, Solana Rust programs must pull in the
 [solana-program](https://crates.io/crates/solana-program) crate.
 
-Solana BPF programs have some [restrictions](#restrictions) that may prevent the
+Solana SBF programs have some [restrictions](#restrictions) that may prevent the
 inclusion of some crates as dependencies or require special handling.
 
 For example:
 
 - Crates that require the architecture be a subset of the ones supported by the
   official toolchain. There is no workaround for this unless that crate is
-  forked and BPF added to that those architecture checks.
+  forked and SBF added to that those architecture checks.
 - Crates may depend on `rand` which is not supported in Solana's deterministic
   program environment. To include a `rand` dependent crate refer to [Depending
   on Rand](#depending-on-rand).
@@ -68,7 +68,7 @@ machine which can be used for unit testing:
 $ cargo build
 ```
 
-To build a specific program, such as SPL Token, for the Solana BPF target which
+To build a specific program, such as SPL Token, for the Solana SBF target which
 can be deployed to the cluster:
 
 ```bash
@@ -305,12 +305,12 @@ Rust's `panic!`, `assert!`, and internal panic results are printed to the
 
 ```
 INFO  solana_runtime::message_processor] Finalized account CGLhHSuWsp1gT4B7MY2KACqp9RUwQRhcUFfVSuxpSajZ
-INFO  solana_runtime::message_processor] Call BPF program CGLhHSuWsp1gT4B7MY2KACqp9RUwQRhcUFfVSuxpSajZ
+INFO  solana_runtime::message_processor] Call SBF program CGLhHSuWsp1gT4B7MY2KACqp9RUwQRhcUFfVSuxpSajZ
 INFO  solana_runtime::message_processor] Program log: Panicked at: 'assertion failed: `(left == right)`
       left: `1`,
      right: `2`', rust/panic/src/lib.rs:22:5
-INFO  solana_runtime::message_processor] BPF program consumed 5453 of 200000 units
-INFO  solana_runtime::message_processor] BPF program CGLhHSuWsp1gT4B7MY2KACqp9RUwQRhcUFfVSuxpSajZ failed: BPF program panicked
+INFO  solana_runtime::message_processor] SBF program consumed 5453 of 200000 units
+INFO  solana_runtime::message_processor] SBF program CGLhHSuWsp1gT4B7MY2KACqp9RUwQRhcUFfVSuxpSajZ failed: BPF program panicked
 ```
 
 ### Custom Panic Handler
@@ -369,7 +369,7 @@ for more information.
 
 ## ELF Dump
 
-The BPF shared object internals can be dumped to a text file to gain more
+The SBF shared object internals can be dumped to a text file to gain more
 insight into a program's composition and what it may be doing at runtime. The
 dump will contain both the ELF information as well as a list of all the symbols
 and the instructions that implement them. Some of the BPF loader's error log

docs/src/developing/on-chain-programs/faq.md

@@ -18,7 +18,7 @@ Depth](developing/programming-model/calling-between-programs.md#call-depth)
 
 ## `CallDepthExceeded` error
 
-This error means the BPF stack depth was exceeded.
+This error means the SBF stack depth was exceeded.
 
 See [call depth](overview.md#call-depth)
 

docs/src/developing/on-chain-programs/overview.md

@@ -26,7 +26,7 @@ native instructions.
 
 ## Memory map
 
-The virtual address memory map used by Solana BPF programs is fixed and laid out
+The virtual address memory map used by Solana SBF programs is fixed and laid out
 as follows
 
 - Program code starts at 0x100000000
@@ -42,7 +42,7 @@ the attempted violation.
 
 ## Stack
 
-BPF uses stack frames instead of a variable stack pointer. Each stack frame is
+SBF uses stack frames instead of a variable stack pointer. Each stack frame is
 4KB in size.
 
 If a program violates that stack frame size, the compiler will report the
@@ -67,7 +67,7 @@ crates may include functionality that violates the stack frame restrictions even
 if the program doesn't use that functionality. If the program violates the stack
 size at runtime, an `AccessViolation` error will be reported.
 
-BPF stack frames occupy a virtual address range starting at 0x200000000.
+SBF stack frames occupy a virtual address range starting at 0x200000000.
 
 ## Call Depth
 
@@ -126,7 +126,7 @@ added to support writable data.
 
 ## Signed division
 
-The BPF instruction set does not support [signed
+The SBF instruction set does not support [signed
 division](https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html#q-why-there-is-no-bpf-sdiv-for-signed-divide-operation).
 Adding a signed division instruction is a consideration.
 
@@ -156,27 +156,27 @@ loader see:
 
 ### Deployment
 
-BPF program deployment is the process of uploading a BPF shared object into a
+SBF program deployment is the process of uploading a BPF shared object into a
 program account's data and marking the account executable. A client breaks the
-BPF shared object into smaller pieces and sends them as the instruction data of
+SBF shared object into smaller pieces and sends them as the instruction data of
 [`Write`](https://github.com/solana-labs/solana/blob/bc7133d7526a041d1aaee807b80922baa89b6f90/sdk/program/src/loader_instruction.rs#L13)
 instructions to the loader where loader writes that data into the program's
 account data. Once all the pieces are received the client sends a
 [`Finalize`](https://github.com/solana-labs/solana/blob/bc7133d7526a041d1aaee807b80922baa89b6f90/sdk/program/src/loader_instruction.rs#L30)
-instruction to the loader, the loader then validates that the BPF data is valid
+instruction to the loader, the loader then validates that the SBF data is valid
 and marks the program account as _executable_. Once the program account is
 marked executable, subsequent transactions may issue instructions for that
 program to process.
 
-When an instruction is directed at an executable BPF program the loader
+When an instruction is directed at an executable SBF program the loader
 configures the program's execution environment, serializes the program's input
 parameters, calls the program's entrypoint, and reports any errors encountered.
 
 For further information see [deploying](deploying.md)
 
 ### Input Parameter Serialization
 
-BPF loaders serialize the program input parameters into a byte array that is
+SBF loaders serialize the program input parameters into a byte array that is
 then passed to the program's entrypoint, where the program is responsible for
 deserializing it on-chain. One of the changes between the deprecated loader and
 the current loader is that the input parameters are serialized in a way that

docs/src/developing/programming-model/accounts.md

@@ -45,7 +45,7 @@ If an account is marked "executable" in its metadata, then it is considered a
 program which can be executed by including the account's public key in an
 instruction's [program id](transactions.md#program-id). Accounts are marked as
 executable during a successful program deployment process by the loader that
-owns the account. When a program is deployed to the execution engine (BPF deployment),
+owns the account. When a program is deployed to the execution engine (SBF deployment),
 the loader determines that the bytecode in the account's data is valid.
 If so, the loader permanently marks the program account as executable.
 

docs/src/developing/programming-model/runtime.md

@@ -52,14 +52,14 @@ the transaction may perform, and operational bounds the transaction must adhere
 to.
 
 As the transaction is processed compute units are consumed by its
-instruction's programs performing operations such as executing BPF instructions,
+instruction's programs performing operations such as executing SBF instructions,
 calling syscalls, etc... When the transaction consumes its entire budget, or
 exceeds a bound such as attempting a call stack that is too deep, the runtime
 halts the transaction processing and returns an error.
 
 The following operations incur a compute cost:
 
-- Executing BPF instructions
+- Executing SBF instructions
 - Passing data between programs
 - Calling system calls
   - logging
@@ -94,9 +94,9 @@ log_pubkey_units: 100,
 
 Then any transaction:
 
-- Could execute 1,400,000 BPF instructions, if it did nothing else.
+- Could execute 1,400,000 SBF instructions, if it did nothing else.
 - Cannot exceed 4k of stack usage.
-- Cannot exceed a BPF call depth of 64.
+- Cannot exceed a SBF call depth of 64.
 - Cannot exceed invoke stack height of 5 (4 levels of cross-program invocations).
 
 > **NOTE:** Since the compute budget is consumed incrementally as the transaction executes,

docs/src/developing/programming-model/transactions.md

@@ -133,8 +133,8 @@ program will process this instruction. The program's account's owner specifies
 which loader should be used to load and execute the program, and the data
 contains information about how the runtime should execute the program.
 
-In the case of [on-chain BPF programs](developing/on-chain-programs/overview.md),
-the owner is the BPF Loader and the account data holds the BPF bytecode. Program
+In the case of [on-chain SBF programs](developing/on-chain-programs/overview.md),
+the owner is the SBF Loader and the account data holds the BPF bytecode. Program
 accounts are permanently marked as executable by the loader once they are
 successfully deployed. The runtime will reject transactions that specify programs
 that are not executable.

docs/src/history.md

@@ -57,4 +57,4 @@ testnet running 150 nodes on a gigabit network and demonstrated soak tests
 processing an _average_ of 200 thousand transactions per second with bursts
 over 500 thousand. The project was also extended to support on-chain programs
 written in the C programming language and run concurrently in a safe execution
-environment called BPF.
+environment called SBF.

docs/src/implemented-proposals/instruction_introspection.md

@@ -25,4 +25,4 @@ for it and also write the current instruction index and then the bpf program can
 necessary information from there.
 
 Note: custom serialization of instructions is used because bincode is about 10x slower
-in native code and exceeds current BPF instruction limits.
+in native code and exceeds current SBF instruction limits.

docs/src/proposals/comprehensive-compute-fees.md

@@ -50,7 +50,7 @@ A fee could be calculated based on:
      requested amount.  After processing, the actual number of units consumed
      will be known, and the payer will be refunded the difference, so the payer
      only pays for what they used.  Builtin programs will have a fixed cost
-     while BPF program's cost will be measured at runtime.
+     while SBF program's cost will be measured at runtime.
 6. Precompiled programs
    - Precompiled programs are performing compute-intensive operations.  The work
      incurred by a precompiled program is predictable based on the instruction's

docs/src/proposals/embedding-move.md

@@ -34,4 +34,4 @@ All data accounts owned by Move modules must set their owners to the loader, `MO
 
 ### Interacting with Solana programs
 
-To invoke instructions in non-Move programs, Solana would need to extend the Move VM with a `process_instruction()` system call. It would work the same as `process_instruction()` Rust BPF programs.
+To invoke instructions in non-Move programs, Solana would need to extend the Move VM with a `process_instruction()` system call. It would work the same as `process_instruction()` Rust SBF programs.

docs/src/proposals/return-data.md

@@ -1,4 +1,4 @@
-# Return data from BPF programs
+# Return data from SBF programs
 
 ## Problem
 
@@ -44,7 +44,7 @@ block, any of these would cause the transaction or rpc to fail.
 ## Existing solution
 
 The existing solution that Solang uses, writes the return data to the callee account data.
-The caller's account cannot be used, since the callee may not be the same BPF program, so
+The caller's account cannot be used, since the callee may not be the same SBF program, so
 it will not have permission to write to the callee's account data.
 
 Another solution would be to have a single return data account which is passed
@@ -136,9 +136,9 @@ strings in the [stable log](https://github.com/solana-labs/solana/blob/952928419
 
 Solidity on Ethereum allows the contract to return an error in the return data. In this case, all
 the account data changes for the account should be reverted. On Solana, any non-zero exit code
-for a BPF prorgram means the entire transaction fails. We do not wish to support an error return
+for a SBF prorgram means the entire transaction fails. We do not wish to support an error return
 by returning success and then returning an error in the return data. This would mean we would have
-to support reverting the account data changes; this too expensive both on the VM side and the BPF
+to support reverting the account data changes; this too expensive both on the VM side and the SBF
 contract side.
 
 Errors will be reported via sol_log.