Program Execution

Solana Program Execution¶

In Solana, execution refers to the process of running transactions and instructions within the SVM (Solana Virtual Machine). Solana's execution engine, Sealevel, is the core of its high performance, supporting parallel execution, determinism, and efficient resource management.

Sealevel Parallel Runtime¶

Sealevel is Solana's parallel smart contract runtime, fundamentally different from Ethereum's serial execution model.

Parallel Execution Solana can execute multiple non-conflicting transactions simultaneously: - Analyzes the accounts involved in transactions - Identifies non-conflicting transactions - Executes them in parallel across multiple CPU cores

For example: - Transaction A modifies Account X - Transaction B modifies Account Y - A and B can be executed in parallel

Conflict Detection If two transactions both need to write to the same account: - They must be executed serially - Ordered by transaction fee and timestamp - The next one executes only after the previous one completes

This mechanism allows Solana to fully utilize modern multi-core CPUs, achieving high throughput.

Execution Flow¶

1. Transaction Reception After a validator receives a transaction: - Verifies signatures - Checks account balances - Validates blockhash validity

2. Scheduling The scheduler analyzes transactions: - Extracts the accounts involved - Builds an account dependency graph - Groups non-conflicting transactions together

3. Parallel Execution Executed across multiple threads: - Loads account data - Invokes eBPF programs - Updates account state - Records logs and CU consumption

4. State Commitment After successful execution: - Writes updates back to AccountsDB - Updates the Merkle tree - Generates transaction receipts

eBPF Virtual Machine¶

Solana uses eBPF as the execution environment for smart contracts.

Execution Characteristics - JIT Compilation: eBPF bytecode is just-in-time compiled to native machine code - Sandbox Isolation: Programs cannot access system resources - Determinism: Same input always produces the same output - Verifiable: Static analysis ensures safety

Execution Limits - Compute Unit (CU) limits - Call depth limit (4 levels of CPI) - Stack size limit (32KB) - Account data size limit (10MB)

Account Access Model¶

Read-Only vs Writable - Read-only accounts: Multiple transactions can read in parallel - Writable accounts: Exclusively locked, written serially

Pre-declaration Transactions must pre-declare all accounts involved: - Cannot access undeclared accounts during execution - Enables the scheduler to detect conflicts in advance - Supports optimistic concurrency control

Determinism Guarantees¶

Solana execution is fully deterministic:

Same Input - Same transaction - Same account state - Same program code

Same Output - Same state changes - Same log output - Same CU consumption

This ensures all validators can reach consensus.

Performance Optimization¶

1. Prefetching Pre-loads account data into cache to reduce wait time.

2. Pipelining Divides transaction processing into multiple stages: - Receive -> Verify -> Execute -> Commit - Each stage processes different batches in parallel

3. Batch Processing - Batch-loads accounts - Batch-writes state - Reduces I/O overhead

4. SIMD Optimization Leverages CPU SIMD instructions to accelerate: - Signature verification - Hash computation - Data serialization

Execution Failure Handling¶

Failure Causes - CU exhaustion - Program errors (panic, assert failure) - Account validation failure - CPI depth exceeded

Failure Consequences - The entire transaction is rolled back - Account state remains unchanged - Transaction fees are still deducted (to prevent DoS) - Error logs are returned

Comparison with EVM¶

Related Concepts¶

• Sealevel: Solana's parallel runtime engine
• eBPF: The bytecode format for Solana smart contracts
• CU (Compute Units): The unit measuring execution resource consumption
• AccountsDB: The database storing account state