QTube LearnFoundations Beginner
What Is a Blockchain Node?
A node is an instance of client software connected to peers. It is not a wallet, not an account, and not automatically a miner or validator. On Bitcoin, a full node independently validates blocks and transactions under Bitcoin’s consensus rules and usually relays valid data.
In brief
A node is an instance of client software connected to peers. It is not a wallet, not an account, and not automatically a miner or validator.
On Bitcoin, a full node independently validates blocks and transactions under Bitcoin’s consensus rules and usually relays valid data. A pruned full node performs that validation but discards old block files; an archival full node retains them. An SPV client checks proof-of-work headers and Merkle inclusion proofs without validating every transaction in every block.
On Ethereum after The Merge, a full node is two cooperating programs: an execution client (transactions, EVM, state) and a consensus client (fork choice, attestations, finality). A validator client is optional and needs a 32 ETH activation deposit. Ethereum also distinguishes full, archive, and light nodes.
On Solana, an Agave consensus validator votes and can produce blocks, while a typical non-voting RPC node runs validator software to answer queries and forward transactions without participating in consensus. “Node” and “validator” therefore are not interchangeable even within one ecosystem.
Most people reach a chain through someone else’s node (a wallet’s default RPC). That is convenient. It is also a trust and privacy choice.
A node is software talking to peers
ethereum.org’s definition is a good starting point for Ethereum and a usable picture elsewhere: a node is client software connected to other computers running compatible software. The client is the program that implements the protocol rules. The node is a running instance of that program (or, on Ethereum, of two programs) on the network.
Bitcoin.org: a full node fully validates transactions and blocks. Almost all full nodes also accept data from peers, check it, and relay it onward. That relay is how a peer-to-peer network stays a network instead of a set of isolated databases.
The node does not “hold your coins.” Assets are represented in chain state. Depending on its type, a node stores and verifies the ledger itself, verifies selected proofs, or serves a view of data it has processed.
Node is not wallet, not validator
Keep the jobs separate.
| Role | What it does | | --- | --- | | Wallet | Manages signing and account/address information; may use an embedded client or an external node | | Node | Verifies and serves chain data; talks to peers | | Validator / miner | Helps produce the next canonical history, under that network’s rules |
A wallet can talk to your node or to a public RPC. Choosing your own RPC endpoint reduces reliance on a default provider, but wallet telemetry and other network requests can still affect privacy.
On Ethereum, running a non-validating node does not require 32 ETH. The Merge page and the nodes docs both stress this. The 32 ETH figure is for activating a validator, which is extra software and a deposit. Confusing “run a node” with “send 32 ETH” is a common scam pattern.
On Solana, the current Agave operator docs make a practical distinction: a consensus validator votes and may lead block production, whereas a typical RPC node does not vote and instead answers API requests and submits transactions to leaders. Both can run the same validator software, but their responsibilities and operating incentives differ.
Bitcoin: full, pruned, archival, SPV
The Bitcoin developer guide:
- Full nodes independently enforce consensus rules on the blocks and transactions they accept.
- Archival nodes are full nodes that store the entire chain and can serve old blocks.
- Pruned nodes are still full nodes. They validate, then discard old block data to save disk. They cannot serve deep history.
- SPV (simplified payment verification) clients use the same P2P protocol but do not independently verify the whole chain. They depend on full nodes for proofs and relay.
Consensus rules are not the same thing as the P2P protocol. Miners sometimes use private high-speed relay networks. Some wallets use Electrum-style servers. Those are alternative ways to move data. They do not change what a valid block is.
Bitcoin.org’s full-node page exists because lightweight wallets need someone to ask. If too few machines validate and serve, users fall back on centralized APIs. Hardware and bandwidth numbers on that page go stale; treat them as “this is a real computer and a real connection,” not as a shopping list.
During initial block download (IBD) a new Bitcoin node obtains and validates the chain needed to catch up with the tip. Pruning changes how much old block data it retains, not whether it enforces the rules.
Ethereum: two clients, three node types
Since The Merge, an Ethereum full node is execution + consensus.
The execution client (Geth, Nethermind, Besu, Erigon, Reth, and others) gossips transactions, runs the EVM, and holds state. It is the usual JSON-RPC door your wallet knocks on.
The consensus client (Lighthouse, Prysm, Teku, Nimbus, Lodestar, Grandine) gossips blocks and attestations, runs fork choice, and tracks justification and finality. The two talk locally over the Engine API.
A validator client is a third piece. It proposes and attests. It is not required to use Ethereum.
ethereum.org’s node types:
- Full node. Validates blocks and the resulting state. Sync strategies differ: some process from genesis, while others begin from a more recent trusted point and verify forward. Full nodes commonly prune old state while retaining historical blocks and transactions.
- Archive node. A full node that never throws historical state away. Needed if you want “what was this balance at block 4,000,000?” without recomputing. Terabytes. Explorers and indexers use these.
- Light node. Processes headers and verifies provider responses against authenticated roots or consensus signatures instead of executing and storing the full chain. Ethereum’s official light-client page says listed implementations are still in development and not considered production-ready there; do not assume they are the default wallet connection.
Client diversity is a safety property. If almost everyone runs one execution client, a bug in that client can look like a supermajority. Multiple independent implementations exist so that no single codebase should dominate.
Why run one
For you: you check the rules yourself. You can keep addresses off a public RPC. You can host explorers, L2 infrastructure, or a validator on top of data you verified.
For the network: full nodes are what light clients and wallets lean on. They are also the last line if consensus is attacked and the community has to choose which history to follow. ethereum.org is explicit: even if you never stake, a full node still helps.
Running a node is not “free money.” It is disk, bandwidth, uptime, and maintenance. Using a reputable RPC is a reasonable choice if you understand you are trusting that operator’s view of the chain.
What this article is not saying
A node is not a bank. A public RPC is not “the blockchain.” Validator and node are not synonyms. Hardware requirements change; do not copy a 2016 disk figure into a 2026 guide.
Sources & further reading
-
Nodes and clients
Primary · Documentation
Node/client distinction, node types, sync strategies, and reasons to run a node
-
Node architecture
Primary · Documentation
Execution/consensus split, Engine API, and optional validator client
-
Light clients
Primary · Documentation
What light clients verify, sync committees, trade-offs, and implementation status
-
Ethereum Archive Node
Primary · Documentation
Historical state retention versus ordinary full-node pruning
-
Client diversity
Primary · Documentation
Why independent client implementations reduce correlated software risk
-
Running A Full Node
Primary · Documentation
Full node validates and relays; serves lightweight clients; IBD concept
-
P2P Network
Primary · Documentation
Full vs archival vs pruned vs SPV; mempool and IBD
-
Consensus Validator or RPC Node?
Primary · Documentation
Voting consensus validators versus service-oriented RPC nodes
-
What is an RPC Node?
Primary · Documentation
Same software, non-voting role, API queries, and transaction submission