Learn about the differences between clients on Solana and Ethereum.
Table of Contents
Ethereum and Solana are unique blockchains that have multiple diverse validator clients for validating transactions. Having various validator clients helps prevent network disruptions in case a specific client encounters issues. In this chapter, we will introduce validator clients in the Ethereum and Solana ecosystems and discuss the types of nodes that exist.
As Ethereum transitioned from PoW (Proof of Work) to PoS (Proof of Stake), it adopted two types of validator clients: Execution Layer (EL) and Consensus Layer (CL) clients. Execution clients are responsible for receiving new transactions broadcasted on the network, executing them on the EVM, and maintaining the current state and database of all Ethereum data. Consensus clients, on the other hand, implement the consensus algorithm of PoS and achieve consensus on the network based on verified data from execution clients. These two types of clients serve different roles, which is why Ethereum validator nodes typically run both execution and consensus clients. In contrast, Solana combines both functionalities in a single client.
Here is the list of execution clients for Ethereum:
| Client | Language |
| Geth | Golang |
| Besu | Java |
| Nethermind | C# .NET |
| Erigon | Go |
| Reth | Rust |
And here is the list of consensus clients for Ethereum:
| Client | Language |
| Lighthouse | Rust |
| Lodestar | TypeScript |
| Nimbus | Nim |
| Prysm | Go |
| Teku | Java |
Now, let's take a look at Solana's validator clients list:
| Client | Language |
| Solana Labs | Rust |
| Jito-Solana | Rust |
| Firedancer | C++ |
| sig | Zig |
| Agave | Rust |
For Ethereum, you can check the number of nodes operated for each validator client by visiting clientdiversity. For Solana, you can find this information from the Validator Health Report.
Nodes come in various forms depending on their use cases and required conditions. They can range from heavyweight nodes that store all data to lightweight nodes focused solely on processing transactions.
Ethereum classifies nodes into three types based on the scope of data storage and participation in consensus:
For Solana, nodes are divided into two types based on their participation in consensus:
Solana distinguishes RPC nodes from consensus nodes from the start. However, RPC nodes do not participate in voting. Ethereum's RPC nodes are typically based on full nodes or archive nodes.
Why does Solana categorize nodes this way? Unlike Ethereum, Solana generates a high number of transactions per second, and storing the entire blockchain on every node is impractical due to the high transaction volume. Currently, Solana stores data using Google Bigtable, and RPC nodes access data from there. Therefore, Solana focuses less on storing a large amount of data locally, which differs from Ethereum's node categorization criteria.
In summary, here's a comparison:
| Node Type | Ethereum | Solana |
| Node storing all data and participating in consensus. | Archive Node | [n/a] |
| Node storing some data and participating in consensus. | Full Node | Consensus Node |
| Node storing some data and not participating in consensus. | Light Node | RPC Node |
There are RPC services that support both Ethereum and Solana simultaneously, as well as those that support a single chain. Services like Alchemy and Quicknode support both Ethereum and Solana. You can check Solana's various RPC services here.