Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Solana programs compile to sBPF — a Solana-specific variant of the Linux eBPF instruction set. sBPF is much simpler than the EVM (more like a regular 64-bit CPU) and runs at near-native speed. Understanding the runtime is critical for debugging, gas estimation, and protocol-level modifications.
sBPF vs EVM bytecode characteristics.
.so file — use objdump -D to view the sBPF assembly.rbpf on GitHub) and inspect the interpreter loop — it's the same code path the validator runs.Use these three in order. Each builds on the one before.
In one paragraph, explain sBPF and how it relates to Linux eBPF.
Walk me through the difference between EVM (stack machine, 256-bit) and sBPF (register machine, 64-bit) — why each was chosen.
Given a workload that's heavy on big-integer math (e.g. ZK circuit verification), explain why it runs faster on Solana's sBPF + syscall combo than on the EVM.
eBPF lineage:
- Originally Linux kernel "extended Berkeley Packet Filter"
- Used for tcpdump filters, then expanded to general kernel programs
- Solana forked eBPF in 2017 to use for on-chain programs (~10 banned instructions)
Solana sBPF (vs EVM):
Word size: 64-bit (vs EVM's 256-bit)
Register-based: 11 general registers (vs EVM stack-only)
Instruction count: ~150 sBPF opcodes (vs ~140 EVM opcodes)
Branch model: conditional jumps (similar to ARM)
Memory model: linear address space with stack + heap segments
Native speed: executes via rBPF interpreter or JIT compiler
What's banned vs Linux eBPF:
- Variable-length instructions (sBPF is fixed 8-byte)
- Direct map/syscall access (Solana exposes syscalls via host functions)
- Network/file I/O (no kernel calls; runs in user-mode VM)
Why sBPF beats EVM for performance:
Register-based + 64-bit = closer to actual CPU; less interpretation overhead
Same Rust source compiles to wasm-comparable bytecode size
Real-world: same logic 5-30× cheaper in CU than equivalent EVM gas