English
 找回密码
 立即注册

Solana's BPF program and parallel execution model

Anatoly 2025-11-1 09:56 83017人围观 SOL

Why can Solana process 65,000 transactions per second? In the blockchain world, performance is often seen as the “price of decentralization.” Bitcoin trades security for speed, and Ethereum trades versatility for throughput. However, the emergence of Sola
in a decentralized blockchain
picture


Why can Solana process 65,000 transactions per second?

In the blockchain world, performance is often seen as the “price of decentralization.” Bitcoin trades security for speed, and Ethereum trades versatility for throughput. However, SolanaThe emergence of breaks this inherent perception - it achieves theoretically more than 65,000 TPS(Transactions per Second) throughput capacity.

This performance leap is not magic, but is built on multiple levels of architectural innovation: efficient Proof of History (PoH) time synchronization mechanism; Natively supported  Parallel transaction scheduling (Parallel Execution); based on BPF (Berkeley Packet Filter) virtual machine High-performance smart contract execution environment; Strict Account Model and Access Control ; A staged execution framework similar to the GPU pipeline.

Philosophically speaking, Solana is not “another Ethereum chain”;A new computing paradigm. If Ethereum is the "world computer", then Solana is the "world supercomputer".

This article willAn in-depth analysis of Solana's high-performance architecture, understanding its fundamental differences from the EVM, and its implications for future smart contract design.



picture



BPF virtual machine mechanism: the "kernel state" execution environment of the blockchain

1. What is BPF (Berkeley Packet Filter)?

BPF originated from the Linux kernel and is used to efficiently filter network packets (packet filtering). The Solana team has deeply transformed it and evolved into Solana BPF Virtual Machine (SBF VM), becoming the execution engine of smart contracts.

Unlike the EVM, the EVM is an interpreted execution environment designed for "security and determinism"; And SBF VM is a Close to system-level native instructionsSandbox execution environment, you can directly run verified LLVM IR (intermediate code) compilation product

2. Design features of SBF

Near native performance: The Rust compiler compiles source code into BPF bytecode through LLVM, with performance close to that of C language programs;

Sandbox security: Check illegal memory access, stack overflow, and uninitialized variables through static verifier (Verifier);

Common instruction set: Compatible with Linux eBPF tool chain for easy debugging and cross-platform analysis;

Deterministic execution: All external calls, randomness, and time functions need to provide interfaces through Solana runtime.

This architecture gives Solana’s smart contracts unprecedented features——It runs as fast as a native program and as secure as a virtual machine.

3. Compare the key differences of EVM:

project

EVM

Solana BPF VM

language

Solidity / Vyper

Rust / C / C++

Compilation target

Bytecode (EVM instructions)

LLVM → BPF directive

execution model

Explanation and execution

Native instruction level execution

status access

Global storage (storage)

Account Model (Account Data)

Parallelization

single threaded serial

parallel scheduling

Gas billing

Operation command unit

Account access and instruction billing

security

EVM sandbox

OS-level sandbox + verifier

Therefore, BPF is not a "virtual machine" in the traditional sense; “Micro-kernel execution environment” ——It is Linux for the blockchain execution layer.


picture


Account model and data ownership

Solana does not adopt the "global state + address storage" approach like Ethereum. Its execution and state access are entirely based on  Account Model

1. Definition of Account

Each account (Account) is a storage unit, including:Address (Pubkey), Owner (Owner Program ID)Balance (Lamports)Data area (Data)Executable flag

Program is a smart contract, which itself is also a kind of account. Transactions issued by users will call one or more Programs and pass in the list of accounts to be operated.

2. Data ownership and access control

Solana’s key innovations are:All accounts to be accessed must be explicitly declared in the order before the transaction is executed.

This means: the runtime knows which accounts will be modified before execution; If two transactions access a non-overlapping set of accounts, they can Safe parallel execution; The account-level locking mechanism avoids global state locking.

This is implemented for Solana Parallel Transaction Execution Provides a theoretical basis.





picture


Parallel execution and transaction isolation mechanism

1. From serial to parallel: Solana’s innovation

The execution model of EVM is serial in nature because all transactions may modify the global state.; State dependencies cannot be determined before execution ; Therefore, they can only be executed one by one (to avoid status conflicts).

Solana implements "pre-parsing of execution graphs" through the account declaration mechanism: each transaction declares the account to be read and written when submitted.; Establish an execution dependency graph based on account overlap at runtime ; Independent batches of transactions can be executed in parallel.

resultSolana's execution layer can run thousands of transaction threads at the same time, performing batch pipeline execution like a GPU.

2. Transaction Isolation Model

Solana uses Account-level Locking: Write operation account and add exclusive lock; Read operation account plus shared lock ; Conflict detection is done during the scheduling phase, not mid-execution.

This model is similar to that of a database MVCC (Multiple Version Concurrency Control), which not only ensures consistency, but also achieves high parallelism.

3. Time synchronization mechanism: Proof of History (PoH)

Another key underpinning of parallel execution is temporal ordering. PoH provides Cryptographic Clock, allowing different nodes to reach a consensus on the sequence of events without relying on consensus. In other words, PoH is Solana’s “clocking layer” that makes parallelism possible.




picture

Contract deployment and calling model (Program + Instruction)

In Solana, contracts are not “monolithic code” in the traditional sense; Programand InstructionTwo levels of abstract organization.

1. Program

Program is equivalent to the smart contract code in Ethereum. It is deployed as an "executable account" and stores compiled BPF bytecode.

2. Instruction

Instruction is a function call to Program, including the entry function to be executed, parameters, account list, etc.

3. Execution process

Transaction → Instruction(s) → Program(s) → BPF Loader → Execution → Status Update

This design naturally supports: multiple Program combination calls (similar to multi-contract collaboration); Parameter serialization and security verification ; Independent deployment and version management.

The advantage isContract logic can be composed and run like a microservice, rather than one lengthy script.


picture


Development stack: Anchor Framework, Rust SDK, BPF Loader

1. Anchor Framework

Anchor is the most mainstream smart contract development framework on Solana. It encapsulates the underlying complexity of BPF and provides automated IDL (Interface Definition Language); Parameter verification and account check ; ABI generation synchronized with the client.

2. Rust SDK

Anchor is built on Rust, allowing developers to develop blockchain logic with system-level security guarantees. Define account structure and access control through #[derive(Accounts)] and #[account] macros to greatly reduce logic errors.

3. BPF Loader

BPF Loader is Solana's runtime loader, responsible for verifying the legality of bytecodes; Allocate account memory ; Maintain call stack and call context ; Execute instructions and return results.

Different from EVM, BPF Loader runs high-performance ELF format programs directly on the chain, which can be called the "Dynamic Linker" in the blockchain field.





picture


Case: Lending contract performance test vs EVM on Solana

Take a simplified DeFi lending contract as an example to test the performance difference between Solana and EVM:

index

EVM (Ethereum)

Solana BPF

Average TPS

20–30

30,000+

average confirmation time

15s

400ms

Single transaction execution time

50–100ms

3–5ms

Gas cost

dynamic float

low and stable

Concurrent execution

Not supported

Support account-level parallelism

Test results show that Solana isThroughput increased by more than 1000 timesWhile still maintaining low latency and strong consistency. But this performance comes from extremely complex runtime scheduling and verification mechanisms.



picture

The paradox of balance between extreme performance and decentralization

Solana’s architecture makes it a “performance miracle” in the blockchain world, but it also raises a fundamental question:When performance approaches that of centralized systems, can decentralization still exist?

1. Node hardware requirements are high

High throughput means that nodes need to have strong computing capabilities; Extremely high memory and storage requirements ; The number of verification nodes is limited and the degree of decentralization decreases.

2. Network bandwidth bottleneck

Parallel execution requires extremely fast state synchronization. Solana's verification nodes need to have gigabit-level bandwidth, and the threshold is much higher than that of Ethereum.

3. Consensus costs and centralization risks

Although PoH+Tower BFT improves efficiency, the trend of validator concentration exposes Solana to potential power concentration issues.

Therefore, while Solana is pursuing the ultimate in performance, it must also continue to balance the system tension of "efficiency vs. decentralization."





picture


Theoretical Implications: Solana’s Impact on Smart Contract Design

From bytecode to compiled contracts: Smart contract language is changing from scripting (Solidity) to system level (Rust/C);

From single thread to parallel execution: The future execution layer of blockchain must be a parallel scheduling system;

From global status to local accounts: Account model provides more predictable state isolation;

From contract script to on-chain program module: In the future, blockchain applications will tend to be modular and service-oriented.

Solana's model will become an important reference for future high-performance public chains, Layer 2 and even cross-chain virtual machine designs.


picture


The limits of performance and the philosophy of architecture

Solana is not just a high-performance chain; it represents aThe return of systems engineering philosophy. It reshapes the execution paradigm of the blockchain with modern computing technologies such as Rust, LLVM, BPF, PoH, and parallel execution.

It makes people rethink: Is the blockchain a decentralized database or a globally verifiable distributed computer? Is EVM a limitation or a legacy? Is Solana the future, or the other extreme?

Whatever the answer, Solana has engineering proof——The future of smart contracts lies in the integration of high-performance parallel execution and system-level security.


picture


-----The End-----

picture

In this rapidly changing world, blockchain technology is reshaping the future. I will carefully record every change and every opportunity, just to accompany you on the journey of wealth and wisdom. If you also believe that technology can light up life and knowledge can open up possibilities, please follow my official account. Let us gain insight into trends, grasp the pulse of the times, and not miss every opportunity that belongs to us.
There is no end to the sun's arch, All the merits will eventually end up in the sea. When you read this, I believe you know more about blockchain. Every like, comment, follow and retweet of yours is support for our dreams and the strength for us to move forward together!




精彩评论0
我有话说......
TA还没有介绍自己。