What is sBPF
sBPF is the bytecode format all Solana programs are compiled to – it's a Solana-forked version of eBPF, the Berkeley Packet Filter technology that Linux uses to execute sandboxed code within its OS kernel. In other words, a Solana developer typically writes their program in Rust, or, to a much smaller degree, C. That source code is compiled by Rust/C compiler to produce sBPF bytecode which is deployed to chain as bytecode to be interpreted by Solana Virtual Machine (SVM).
To illustrate, think of a person making a speech to a crowd of foreigners. They have two options: they can employ an interpreter who will interpret the message to the crowd sentence by sentence in real-time. This will give very accurate translation, but the speech is slow, and every next message has to wait on the interpretation of the prior. Alternatively, the speaker could pre-translate the entire speech to their foreign counterparts and deliver the translation at the same speed at which the native speech was given. The EVM works like the interpreter, and executes the bytecode step-by-step instruction. sBPF however, is translated once (the process is known as Just-In-Time compiling), into the native code of the validator's processor, and executes in a single thread at native speeds.
How sBPF Works
As previously stated, the BPF technology was chosen by design, not ideology. Linux engineers dedicated years to developing eBPF as an efficient sandbox technology for executing untrusted code within the most critical environment in an OS – the kernel. On top of that, LLVM (the backend compiler technology that compiles Rust/C/C++) already shipped with the technology to compile to BPF bytecode. So Solana forked the technology, removed all the Linux kernel specific parts, added the things required for a blockchain runtime and got a decade of BPF tech for free.
Technically, sBPF is register-based. That is, all the instructions operate over a small amount of registers that are reminiscent of CPU registers. This allows a 1:1 mapping of the instructions to the registers of the CPU, making JIT-compilation cheap and resulting in fast compiled code. This isn't enough by itself to make the technology secure and fast. The technology also relies on verification and metering, both of which are performed by the sBPF loader, which executes before any sBPF code ever gets touched. A sBPF transaction gets a certain amount of compute units – 1.4 million is max – and the SVM metering system runs the program until the transaction runs out of compute units. A transaction is killed before it runs out of time, but after it runs out of money. No need for a loop limit, a transaction can just loop forever as long as it has budget left.
How sBPF Stacks up against EVM and WASM
EVM bytecode is stack-based and specific, instructions push and pop to the stack. The architecture is a good choice for a stack-based interpreter. It is easy to reason about and compile to an abstract stack, but slower to execute and harder to compile directly to machine code. Most EVM clients are still executing instructions at native speed. Other chains have chosen WASM as their standard, such as Polkadot, Near, Cosmos SDK chains and many others. WASM is another popular bytecode format that is also typically executed behind eBPF, and slower by a magnitude.
This isn't just a theoretical matter, as it directly impacts the scalability potential for a given chain. Solana block slot time is a quick 400 milliseconds, and each block can potentially contain thousands of transactions. A program needs to be executed at micro-second speeds to be viable. That means a program that only burns ~5,000 Lamports (at a price of $0.0004) in fees is profitable for validators to execute since it costs them almost nothing to process.
Why sBPF Matters
Let's imagine that we were swapping tokens using Jupiter in the same moment. It's quite possible the route involves two or three tokens being routed through Raydium and Orca pools in the background. Each of these swaps involve calculations and math, calculating how much fee to pay based on a formula and adding/subtracting balance from the accounts being used. It can take tens or hundreds of thousands of compute units. sBPF allows all of that to happen in 1ms or less within each 400ms slot. A transaction on EVM can potentially do the same calculations, just at a slower pace and with much more expensive gas. This is why you see Ethereum aggregators often doing their swaps outside of Ethereum, but Solana is able to do more work on-chain, as the costs are low enough and speeds are fast enough that it can afford it.
As for some of the downfalls of using sBPF, there are a few that should be acknowledged. It's a bit of a niche programming language target, so you don't have all the developers who are Solidity developers. It's got a small ecosystem and a tight sandbox that allows few things to escape, floating points are disallowed, stack sizes are small and you have very little information to debug when there is a low-level bytecode error. There are many benefits that Solidity offers, which means weekend developers and other people who want to quickly prototype and test the system are excluded from the platform. What you get in exchange is the ability to execute at native machine-code speeds which allow for the mathematics of executing blocks in 400ms and being able to offer transactions that costs fractions of a penny. And this is one of the many reasons why Solana is fast.
