Skip To Content

Blockdaemon Documentation

Solana Overview

What is Solana?
Solana Ubiquity Support
Solana Validator Terminology
Solana Consensus Layer
Solana Execution Layer
Solana APIs
Reference Material


What is Solana?

Solana is a high-throughput, proof-of-stake blockchain. It supports 1000+ transactions per second at low fees with fast transaction confirmation.

Due to this high performance, Solana has high hardware requirements (CPU, RAM, SSD, network). Most Solana nodes are hosted on bare-metal hosting rather than cloud or virtualized infrastructure.


Solana Ubiquity Support

Solana is supported by the Blockdaemon Ubiquity API. Ubiquity provides secure and scalable API access without the need to run any nodes.

For more information visit the Ubqiuty Solana Page.


Solana Validator Terminology

Solana uses the term ‘validator’ in a specific way. This is different to the standard usage:

  • In Solana terminology: a validator verifies incoming transactions on the blockchain.
  • In common terminology: a validator participates in consensus and produces blocks.

For clarity, we use the common definition of ‘validator’.


Consensus Layer

Nodes participating in the Solana network verify all new transactions going through. Solana does not support light clients.

Data Availability (History)

Nodes in the Solana network only save the last few thousand blocks locally which amounts to ~1.5 TB of data. The retransmit window is the window of recent block history that Solana nodes will send to other nodes upon request. This allows the nodes to catch up to the rest of the network by replaying those older blocks (faster than the blockchain progresses).

Data Availability (State)

When a node has no blockchain history synced or is behind the retransmit window, it won’t be able to catch up as the blocks are unavailable on-demand. Nodes will instead retrieve a snapshot of the latest accounts from a trusted node or validator.

When unpacking the snapshot, nodes will verify that the data stored within is inherently correct (Merkle proofs). There is however no proof that the snapshot contains a set of accounts (bank) that is canonical with regards to blockchain history.

Leader Schedule

A public, epoch-based stake-weighted (PRNG) random sampling of validators.

Solana has 432,000 slots per epoch which amounts to ~2 days. Each epoch has a randomly generated predefined leader schedule that defines which validator is expected to produce a block per slot. A slot can then either contain a block or not (skipped slot).

The probability at which a leader is elected is weighted by stake.

The PRNG used is ChaCha20 seeded by epoch number. Surprisingly, this means that all upcoming leader schedules would be predictable if stakes didn’t change.

Connectivity

Everything is public and stateless

Every validator on the Solana network has a public IP address and accepts transactions from any node on the Solana network.

Solana mostly uses UDP for consensus messages. This is stateless, therefore no handshakes or long-lived connections are required. In effect, each Solana node is ‘connected’ to thousands of other Solana peer nodes at once.

Transaction Propagation

Unconfirmed transactions sent directly to validators.

Non-validating nodes will follow the leader schedule and send transactions directly to the upcoming validators. This ensures transactions reach the current leader (that will include the tx in a block) in the least possible amount of latency. It also means there is no mempool. Validators that failed to include a transaction will however forward it to the next upcoming validator.

Block Propagation

A mix between predefined block propagation paths & random flooding.

Once a validator has assembled a block, it needs to propagate this block to all other Solana nodes in the network. The amount of data that has to be sent to a large number of nodes (tens of thousands) poses a significant engineering challenge.

Solana has opted to group validators into neighbourhoods/committees with derived ‘plans’ on how to distribute blocks based on the consensus protocol with randomness sprinkled in. This maximizes robustness by achieving predictable degrees of data amplification while introducing just enough unpredictability to be censorship-resistant.


Execution Layer

Solana nodes are monoliths, meaning the consensus layer and execution layer clients reside in the same process: The Solana-validator (both for validators and non-validating nodes).

On-chain programs (smart contracts)

Solana is programmable using the C or Rust programming languages. Anyone can upload compiled programs as ELF files using the BPF bytecode machine language.

Anchor IDL (interface definition language) is useful for interoperability: Introduction | ⚓ Anchor

BPF virtual machine

BPF (Berkely packet filter) is most known for its use in the Linux and BSD kernels. The BPF runtime allows safe and predictable execution of arbitrary code at high performance (similar to WebAssembly).

BPF code is verified for correctness and then JIT-compiled to native x86_64 code before execution. The compiled machine code is cached for further executions.


Solana APIs

The following APIs exist to interact with Solana.

JSON-RPC – The Solana JSON-RPC is the primary way to submit transactions and read state and history. For more information visit JSON RPC API | Solana Docs

WebSocket Pub/Sub – The WebSocket Pub/Sub is an extension of the JSON-RPC API that allows clients to subscribe to push notifications of on-chain events through a WebSocket stream. For more information visit JSON RPC API | Solana Docs


Reference Material

 

We don't support Internet Explorer

Please use Chrome, Safari, Firefox, or Edge to view this site.