Solana Validators
Starting from scratch
What is it?
TLDR -> A solana validator is a node (hardware) of the networks that performs the computations for producting blocks or validating transactions. A solana validator client is a piece of software that allows validators to connect to the network and perform their duties.
A validator is a term for a node in the blockchain. This nodes play a critical role on the network's intergrity and security. Actions they perform: Validate transactions (sigcheks to ensure txs are legit), produce blocks, and participate in consensus (compliance with network rules).
A validator client on the contrary, is a software developed to allow validators to connect to the Solana network and perform their duties. These clients, allow validators to execute the needed actions for validating txs, producing blocks, etc.
RPC Nodes
RPC nodes are also nodes that take part in the Solana blockchain. However, they differ from a usual validator in that they do not produce blocks. Instead, they are used to interact with the network and perform actions such as querying the network, sending transactions, etc.
RPC nodes produvde APIs for developers to perform such activities and do not take part int the consesus or block creation process.
These nodes also give real-time data access without the overhead of the running validator (that can be a couple slots behind)
Note: A solana validator node can also be an RPC node (affecting their performance) but an RPC node would never be a validator node
WTF does a validator node do exactly ?
As we said, they are responsible for proposing new blocks as well as valiadting them, participating in the consensus protocol. Of course, they do not do it for free, as they earn rewards based on performance and updatime. For block validation, the solana go-to protocol is PoH (Proof of History) while proposing a delegated proof of stake for consensus.
Among their main functionalities we can find:
-
Block Production:
- Validators take turns to be the leader of the slot
- If a validator is not the leader, it forwards newly tx to the leader
- When it is the leader, it aggregates txs from various validators into a new block
- Uses PoH to timestamp txs
- Broadcast the newly timestamped block to the network
-
Block Validation and replay:
- When a validator receives the latest generated block from the leader, it re-executes (replays) it, performing several checks to ensure it is valid
- These checks include sigchecks, format correctness and alignment with PoH
- Each validator expects to compute the same exact final signature of the updated ledger state, which gives them the confidence to vote for the new block of transactions.
-
Participate in Consensus:
- Uses dPoS (Delegated Proof of Stake)
- Vote on blocks in proportion to their staked Solana
- The higher the amount of SOL staked on a validator the more weight it has in the consensus process and the higher t he likelyhood of being a leader.
- At least two thirds of the validators need to vote in favor of a block for it to be accepted
- Economically incentivized through rewards to maintain high uptime and optimal performance
- Penalty for downtime or missed slots
Current Validator clients
-
Agave
- Developed in Rust by Anza (former Solana Labs)
- First validator client released
- Audited -> secure and reliable
- Actively maintained by Anza
-
Jito Solana
- Developed in Rust by Jito Labs
- Implements MEV rewards
- Incorporates an MEV marketplace directly into its codebase.
- Validators and stakers to earn additional rewards though MEV.
- MEV searches submit transaction bundles to Jito-Solana marketplace and validators include the highest bidding in their blocks.
- Implements block engine
- Simulates transasctions combination and forwards the highest paying to the slot leaders for block inclussion.
- Integrate off-chain relayer, searcher and validators
- Compatible with all current hardware and ease of use
- Reeduce spam on the network using a relayer and auctions for high-value txs -> prioritize legitimate txs and discourage spam
-
Sig
- Developed in Zig by Syndica
- Optimized for Reads-per-second
- Designed to handle heavy read calls more efficiently, thus reducing slot lag.
-
Firedancer
- Developed in C by Jump Crypto
- Designed for High throughput
- Designed to process over 1 million TPS -> pushing the theoretical limit of 50k in the Solana network
- Zero-Downtime upgrades:
- Upgrading versions of Firedancer is designed to be seamless, with the ability to replace individual tiles without downtime.
- Module Architecture:
- Firedancer comprises independent C processed (known as tiles) that work together to process varioous operations such as packet processing, block production, or signture verification.
- Allows the full use of the CPU core abd enhaces security and fault tolerance