Runtime

​

Overview

• Executing smart contract programs (Solana programs)
• Managing account state and balances
• Enforcing access control and security rules
• Parallelizing non-conflicting transactions
• Recording execution in Proof of History

​

Core Design Principles

​

Explicit Dependencies

pub struct Transaction {
    pub signatures: Vec<Signature>,
    pub message: Message,
}

pub struct Message {
    pub account_keys: Vec<Pubkey>,  // All accounts accessed
    pub instructions: Vec<CompiledInstruction>,
    // ...
}

• Detect conflicts before execution
• Schedule non-conflicting transactions in parallel
• Prevent dynamic memory allocation during execution

​

Parallel Execution

1. Load accounts - Fetch account data from AccountsDB
2. Detect conflicts - Identify transactions accessing the same writable accounts
3. Execute in parallel - Run non-conflicting transactions simultaneously
4. Commit atomically - All instructions in a transaction succeed or all fail

​

Account Model

pub struct Account {
    pub lamports: u64,          // Balance in lamports (1 SOL = 1B lamports)
    pub data: Vec<u8>,          // Program-specific state
    pub owner: Pubkey,          // Program that owns this account
    pub executable: bool,       // Whether this account contains executable code
    pub rent_epoch: Epoch,      // Next epoch to collect rent
}

​

Account Ownership Rules

1. Only the owner program may modify account data
   • Prevents unauthorized state changes
   • Data is zero-initialized on assignment
2. Only the owner can spend lamports
   • Programs can only debit accounts they own
   • Anyone can credit (send to) any account
3. Accounts assigned to a program cannot be reassigned
   • Once owned, always owned by that program

​

Transaction Execution

​

Execution Pipeline

Loaded Accounts → Execute Programs → Check Invariants → Commit State

1. Load - Fetch all accounts into memory
2. Execute - Run each instruction in sequence
3. Verify - Check balance invariants and rules
4. Commit - Write changes back to AccountsDB

​

Runtime Invariants

1. Balance conservation - Total lamports before = total after
2. Read-only accounts unchanged - Balances remain identical
3. Atomic execution - All instructions succeed or all fail
4. Owner exclusivity - Only owners modify account data

​

Program Execution

pub type Entrypoint = unsafe extern "C" fn(
    program_id: &Pubkey,
    accounts: &[AccountInfo],
    instruction_data: &[u8],
) -> ProgramResult;

​

Instruction Processing

1. Loads accounts - Maps public keys to account data
2. Invokes program - Calls the program’s entrypoint
3. Returns result - Success or error
4. Commits changes - Updates account state on success

​

Cross-Program Invocation (CPI)

invoke(
    &instruction,           // Instruction to execute
    &account_infos,        // Accounts to pass
)?;

• Program composability
• Modular smart contract design
• Shared program logic
• Secure delegation of authority

​

Solana Virtual Machine (SVM)

​

eBPF Runtime

• Deterministic - Same input always produces same output
• Fast - JIT compilation for near-native performance
• Safe - Sandboxed execution prevents system access
• Verifiable - Bytecode is verified before deployment

​

Compute Budget

pub struct ComputeBudget {
    pub max_units: u64,           // Maximum compute units
    pub heap_size: usize,         // Heap size in bytes
    pub log_units: u64,           // Logging budget
    pub log_64_units: u64,        // Data logging budget
}

• 200,000 compute units per instruction
• 1,400,000 compute units per transaction
• 32 KB heap per program invocation

​

Syscalls

• sol_log_* - Logging for debugging
• sol_invoke_signed - Cross-program invocation
• sol_create_program_address - PDA derivation
• sol_get_clock_sysvar - Access cluster time
• sol_keccak256 - Cryptographic hashing

​

Banking Stage Integration

pub struct BankingStage {
    // Transaction scheduling
    scheduler: TransactionScheduler,
    // Parallel execution
    workers: Vec<Worker>,
    // Result collection
    recorder: TransactionRecorder,
}

1. Receives transactions - From SigVerify stage
2. Locks accounts - Reserves accounts for execution
3. Schedules execution - Assigns to worker threads
4. Records in PoH - Timestamps executed transactions
5. Returns results - Success or failure per transaction

​

Unified Scheduler

• Multi-threaded execution - Distributes work across cores
• Account locking - Prevents conflicting access
• Priority queue - Processes high-fee transactions first
• Look-ahead scheduling - Finds parallelizable transactions

​

Sysvar Accounts

• Clock - Current slot, epoch, and timestamp
• EpochSchedule - Slots per epoch configuration
• Rent - Rent calculation parameters
• StakeHistory - Historical stake activations
• SlotHashes - Recent slot hashes for verification

​

Program Loading and Caching

pub struct LoadedPrograms {
    entries: HashMap<Pubkey, Arc<LoadedProgram>>,
}

pub struct LoadedProgram {
    pub program: Arc<ProgramRuntimeEnvironment>,
    pub account_size: usize,
    pub deployment_slot: Slot,
    pub effective_slot: Slot,
}

• Programs are compiled once and reused
• Cache is updated when programs are upgraded
• LRU eviction prevents unbounded growth

​

Transaction Fees

1. Base fee - Minimum fee per signature
2. Compute fee - Based on compute units consumed
3. Prioritization fee - Optional fee for priority
4. Account creation - Rent-exempt minimum for new accounts

​

State Commitment

1. AccountsDB update - Modified accounts written to cache
2. Bank hash update - Cryptographic hash of all accounts
3. PoH recording - Transaction hash recorded in PoH stream
4. Status recorded - Success/failure logged for RPC queries

​

Built-in Programs

• System Program - Account creation and transfers
• Stake Program - Staking and delegation
• Vote Program - Validator voting
• BPF Loader - Deploys and upgrades programs
• Config Program - Stores configuration data

​

Next Steps

• Learn about validator anatomy
• Understand consensus mechanisms
• Explore cluster operations