Solana Node

Understanding Proof-of-History, Sealevel, and Client Diversity.

Solana Node Architecture

Unlike Ethereum's modular "Two-Client" model, Solana nodes currently operate as a monolithic, high-performance state machine. The protocol is designed to maximize hardware utilization, using every available CPU core to process transactions in parallel.

To run a Solana node effectively, you must understand three core architectural pillars: Proof of History (PoH), Pipeline Processing, and the Client Landscape.

1. The Processing Pipeline (TPU & TVPU)

In Ethereum, transactions wait in a "mempool" until a validator picks them up. In Solana, there is effectively no mempool.

Transactions are forwarded immediately to the current leader (via a protocol called Gulf Stream). The validator processes them through a rigorous hardware pipeline:

  • Fetch Stage: Ingests packets from the network.

  • SigVerify: Uses the CPU (and potentially GPU) to verify cryptographic signatures instantly.

  • Banking Stage: Transactions are ordered and executed.

  • Proof of History (PoH): A cryptographic clock that timestamps the transactions, allowing the network to agree on time without constant chatter.

🚀 Impact on Ops:

Because of this pipeline, CPU clock speed and core count are critical. If your CPU cannot verify signatures fast enough, your node will drop packets and fall behind the network.

2. Parallel Execution (Sealevel)

The defining feature of Solana is Sealevel.

  • Ethereum (EVM): Single-threaded. One transaction is processed at a time.

  • Solana (SVM): Multi-threaded. Thousands of transactions are processed simultaneously.

Sealevel analyzes transactions to see which "State Accounts" they touch. If two transactions touch different accounts (e.g., Alice sends to Bob, and Charlie sends to Dave), they are executed at the exact same time on different CPU cores.

3. Client Implementations

For years, Solana had only one client. Today, the ecosystem is maturing into a multi-client network, similar to Ethereum.

Client

Status

Optimization Focus

Recommended For

Agave (formerly Solana Labs)

Mainnet

The Standard. Written in Rust. This is the reference implementation used by the majority of the network.

General purpose, Voting, and standard RPC.

Jito-Solana

Mainnet

MEV-Enabled. A fork of Agave that includes an out-of-protocol blockspace auction bundle mechanism.

Validators. Almost all institutional validators run Jito to capture MEV rewards.

Firedancer

Testnet

Performance. Written in C++ by Jump Crypto. Designed to process 1M+ TPS by rewriting the networking stack from scratch.

Future standard for high-frequency trading & institutional RPC.

Sig

Devnet

Read-Optimized. Written in Zig by Syndica. Optimized for RPC read calls.

RPC Providers (Future).

4. Node Roles

When setting up your infrastructure, you will configure your node for one of two distinct roles:

A. Validator Node (Voting)

  • Function: Produces blocks and votes on the validity of other blocks.

  • Risk: High. Requires "Identity Keys" and "Vote Keys" to be online.

  • Economics: Earns inflation rewards + block rewards (MEV).

  • Hardware: Requires high-frequency CPU.

B. RPC Node (Non-Voting)

  • Function: Serves API requests (read/write) to users and dApps.

  • Risk: Moderate. No voting keys are required.

  • Hardware: Requires massive RAM (512GB+) and Indexing Indexes to serve getProgramAccounts requests efficiently.

PreviousUpdating Consensus ClientsNextStep 1: Prerequisite

Last updated