Tech Talk: Blueshift - Demystifying SBPF and Comparing Compilers

The Solana developer experience has been notoriously challenging, and according to Blueshift's Claire Fan, much of that pain stems from the ecosystem's approach to compiler tooling. At Breakpoint 2025, Fan presented a compelling case for why Solana should embrace upstream eBPF technology rather than maintaining a heavily customized fork—a change that could dramatically simplify how developers build on the network.

Summary

Top Projects

Lulo

Score: 7,586.13

Bonk

Score: 4,806.12

Sphere

Score: 2,544.42

Moonwalk

Score: 2,026.11

Claire Fan from Blueshift delivered a technical deep-dive into Solana's SBPF (Solana Berkeley Packet Filter) bytecode format and explained why the current approach to compiler tooling creates unnecessary friction for developers. The core issue? Solana created a custom SBPF backend and maintains a fork of the Rust compiler, which means upstream improvements are slow to arrive—or sometimes impossible to integrate due to divergence.

Fan argued that this complexity is largely unnecessary. While eBPF (extended Berkeley Packet Filter) was designed for constrained kernel environments, the LLVM compiler infrastructure that Solana uses is capable of supporting features beyond these limitations. The key insight is that with the right transformation path and proper compiler configuration, developers could leverage upstream tools directly.

The presentation walked through the anatomy of Solana program bytecode, explaining how programs are structured using the ELF (Executable and Linkable Format) standard. Fan demonstrated that by understanding these internals, developers can appreciate where simplifications are possible—particularly around syscalls and dynamic relocation, which currently add significant complexity to the toolchain.

Blueshift's solution, the SBPF linker, represents a practical step toward this simplified future. By working with upstream eBPF rather than against it, the tool can generate valid Solana programs with minimal transformation. Fan concluded with a call to action for the ecosystem to become better contributors to the open-source technologies they depend on, rather than maintaining isolated forks.

Key Points:

The Problem with Solana's Current Compiler Approach

Solana's developer experience challenges are well-documented within the community, and Fan pointed to the toolchain as a significant contributor. Rather than adapting from upstream eBPF (the standard Berkeley Packet Filter target used in Linux kernels), Solana created a custom SBPF backend and maintains its own fork of the Rust compiler.

This approach creates a maintenance burden and delays the adoption of improvements from the broader ecosystem. When the upstream Rust compiler or LLVM receives optimizations or bug fixes, integrating these changes into Solana's fork takes considerable time and effort. In some cases, the divergence becomes so significant that certain improvements simply cannot be pulled down at all. Fan argued that this situation is avoidable because LLVM, the underlying compiler infrastructure, is well-equipped to handle targets beyond eBPF's original kernel-focused limitations.

Understanding Compiler Pipelines and Bytecode Generation

Fan took time to demystify compilers for the audience, emphasizing that they shouldn't be treated as black boxes. A compiler is simply software that takes source code as input, runs it through a series of transformation pipelines, and generates deployable code for target hardware. This is the first layer that makes programs portable—allowing the same Rust code to run on Windows, macOS, or even a Raspberry Pi.

For BPF targets, the final output uses the ELF format (Executable and Linkable Format), which starts with ELF headers and program headers, followed by the actual code sections, and ends with section headers. Computers don't read these files directly—they read binaries—so the compilation process must package everything into a bytecode format that the target machine understands.

Anatomy of a Solana Program's Bytecode

Fan provided a detailed walkthrough of how Solana programs are structured at the bytecode level. The ELF header comes first, containing architecture information and the entry point that identifies which instruction executes first when the program starts. Following this are three program headers for dynamic programs—though Fan noted that static programs don't require any program headers at all.

Currently, the only thing making programs dynamic is syscalls, because the SVM (Solana Virtual Machine) performs dynamic relocation for these system calls. This insight led Fan to advocate for static syscalls, which would eliminate the need for program headers entirely and save bytes in the final program size. The text section contains the actual code, while read-only data (like strings) is stored in a separate section and referenced by instructions. Multiple section tables exist solely to facilitate dynamic syscall relocation—another area where static syscalls could simplify things dramatically.

The Upstream eBPF Path

Five years ago, BPF target support was added to the Rust compiler by an Italian developer, enabling kernel developers to write Rust programs that compile to BPF bytecode for deployment in Linux kernels. Due to Rust's compilation model, a linker was added as part of this target support, since Rust compiles each crate as a standalone unit that must be merged into a single executable.

Fan explained the key differences between upstream eBPF bytecode and what Solana expects. Upstream eBPF performs relocation for read-only data, which must be reversed to encode offsets directly into load instructions for Solana. Additionally, upstream eBPF uses static syscalls, requiring conversion to dynamic relocation-based syscalls for current Solana compatibility—though Fan noted that adopting static syscalls would eliminate this conversion step entirely.

Blueshift's SBPF Linker Solution

Blueshift developed an SBPF assembler that operates independently of any LLVM toolchain, which now powers their SBPF linker. The assembler parses assembly programs into an abstract syntax tree (AST) capable of calculating offsets, sizes, generating sections and headers, encoding instructions, and handling dynamic relocation for syscalls. This enables direct bytecode generation for Solana programs.

The SBPF linker works by first calling the standard BPF linker to generate a single object file from upstream eBPF, then re-parsing that object file and generating a Solana program from the AST. This approach proves that working with upstream eBPF to produce valid Solana programs requires only two things: a BPF linker for compilation and a repackaging tool to convert the bytecode into a format SVM understands.

A Call for Better Open Source Citizenship

Fan closed with an appeal for the Solana ecosystem to improve its relationship with the open-source technologies it depends on. Rather than being "bad consumers" who fork and diverge, the community should contribute optimizations back upstream so developers outside Solana can benefit as well.

From an engineering perspective, Fan argued this makes practical sense: the more people use an optimization path, the better tested it becomes, and more edge cases get discovered. The SBPF linker opens up this collaborative path, potentially benefiting both Solana developers and the broader eBPF ecosystem.

Facts + Figures

• Solana maintains a custom SBPF backend and a fork of the Rust compiler, creating integration delays with upstream improvements

• The BPF target was added to the Rust compiler five years ago by an Italian developer, enabling Rust-to-BPF compilation for kernel use

• Static syscalls could eliminate the need for program headers in Solana programs, saving bytes and reducing complexity

• The ELF (Executable and Linkable Format) is the standard format for BPF targets, consisting of headers, code sections, and section tables

• Blueshift's SBPF assembler operates independently of any LLVM toolchain

• Only two tools are needed to generate Solana programs from upstream eBPF: a BPF linker and a repackaging tool

• The current dynamic relocation system for syscalls requires multiple section tables in every Solana program

• LLVM supports targets beyond eBPF's kernel-focused limitations, making custom backends unnecessary in Fan's view

• Rust compiles each crate as a standalone compilation unit, requiring a linker to merge dependencies into executables

Top quotes

• "I think this tweet pretty much sums up the developer experience of Solana that it is pretty terrible."

• "In my opinion, there's no real reason to do that because yes, eBPF is very constrained... but Solana compilers use LLVM that supports all kinds of targets that don't have these limitations."

• "Compilers are just software. It's a software that takes the source code of your program as input and runs through pipelines of transforms and generate code that you can deploy on your hardware."

• "So now that you understand this, you can create a Solana program by just using Vim. But don't do it. You're getting blocked by many people after this talk."

• "We should stop being a bad consumer of the technology we're using. We should try to be a good contributor."

• "If I have an optimization path, the more people use it, the more it will become better because it will be better tested and more edge cases will be discovered."

• "I hope things have become somewhat trivial here. To generate a Solana program from upstream eBPF, we only need two things."

Questions Answered

Why is Solana's developer experience often criticized?

Part of the challenge stems from Solana's toolchain approach. Instead of adapting from upstream eBPF (the standard Berkeley Packet Filter implementation), Solana created a custom SBPF backend and maintains a fork of the Rust compiler. This means improvements from the broader Rust and LLVM ecosystems take longer to reach Solana developers, and sometimes the divergence becomes so significant that certain improvements can't be integrated at all. This creates unnecessary friction for developers building on the network.

What is the ELF format and why does it matter for Solana programs?

ELF stands for Executable and Linkable Format, and it's the standard bytecode format for BPF targets. Solana programs are structured as ELF files, starting with headers that define the architecture and entry point, followed by program headers (for dynamic programs), code sections, read-only data sections, relocation tables, and section headers. Understanding this structure is crucial because it reveals where simplifications are possible—for instance, static syscalls could eliminate the need for program headers and multiple section tables entirely.

What are static syscalls and why would they improve Solana?

Currently, Solana programs use dynamic relocation for syscalls, meaning the SVM must look up syscall locations at runtime using multiple section tables embedded in the program. Static syscalls would instead encode the hash of each syscall function directly into the code instructions. This approach would eliminate the need for program headers and relocation tables, reducing program size and simplifying the compilation process. Upstream eBPF already uses static syscalls, so adopting this approach would also make it easier to leverage upstream tools.

How does Blueshift's SBPF linker work?

The SBPF linker leverages Blueshift's SBPF assembler, which operates independently of any LLVM toolchain. The linker first calls the standard BPF linker to compile a program into a single object file using upstream eBPF. It then parses that object file and uses an abstract syntax tree to generate a properly formatted Solana program. This approach demonstrates that generating Solana programs from upstream eBPF is achievable with just two tools: a standard BPF linker and a repackaging utility.

Why should Solana developers contribute back to upstream projects?

Fan argued that the Solana ecosystem should stop being "bad consumers" of open-source technology by forking and diverging without contributing back. From a practical engineering standpoint, contributing optimizations upstream means more developers will use and test those code paths, leading to better stability and the discovery of more edge cases. This collaborative approach benefits everyone—both Solana developers who gain from broader testing, and the wider eBPF community who can leverage Solana-originated improvements.

Can you really create a Solana program using just Vim?

Technically yes—understanding the ELF format and Solana's bytecode structure means you could manually construct a valid program file byte by byte. However, Fan humorously warned against actually doing this, noting "you're getting blocked by many people after this talk." The point was to illustrate that once you demystify the compiler and bytecode format, the underlying technology becomes far less intimidating than it initially appears.