A blockchain node is a computer running the network's client software, connected to other computers running the same software, that keeps a copy of the chain and checks new blocks against the protocol rules. Ethereum.org defines an Ethereum node as "any instance of Ethereum client software that is connected to other computers also running Ethereum software," per its nodes and clients page. Nodes come in three main types, full, archive and light, which differ in how much data they keep and verify.
​

Every wallet balance, dApp screen and block explorer page ultimately reads from a node. This page explains what nodes do, how the three node types differ, what it takes to run one on Ethereum and Solana, and when a team should use a hosted node instead. Sources were fetched on October 13, 2026.
​

A node does three jobs: it stores blockchain data, it verifies every new block and transaction against the consensus rules, and it serves data to wallets and apps that ask for it. Nodes also pass transactions and blocks to their peers, which is how the network spreads information without a central server.
​

On Ethereum, a node runs two programs side by side. The execution client listens for new transactions, executes them in the EVM and holds the latest state, while the consensus client implements proof of stake so the network agrees on validated data, per Ethereum.org nodes and clients docs. Apps reach a node through its JSON-RPC interface. Running your own node lets you "verify the data yourself with your client," per the same page, instead of trusting another operator's answers.
​

The three node types trade storage for capability. Full nodes verify everything but prune old state. Archive nodes keep every historical state and need the most disk. Light nodes keep only block headers and ask full nodes for the rest, which makes them cheap to run but dependent on peers.
​

Full nodes do block-by-block validation, downloading and verifying the block body and state data for each block, per Ethereum.org nodes and clients docs. Some verify from genesis; others start from a recent trusted block, as Geth's snap sync does. Either way they keep only relatively recent state locally and can regenerate older states from snapshots.
​

An archive node is a full node that never deletes downloaded data, so it can answer questions like an account's balance at an old block without recomputing history. Ethereum.org's archive node page puts the disk requirement at 3 TB to 12 TB depending on the client, and notes the network does not depend on archive nodes, since any full node can replay stored transactions to rebuild history.
​

Light nodes download only block headers and request everything else from full nodes, then verify what they receive against the state roots in those headers, per Ethereum.org nodes and clients docs. The same page says Ethereum does not yet support a large population of light nodes, and names Nimbus, Helios and Lodestar as clients focused on them. Those state roots are Merkle roots, explained in What Is a Merkle Tree?
​

No. Every validator runs a node, but most nodes are not validators. A node verifies and relays data; a validator also stakes funds and proposes or attests to blocks. On Ethereum, a solo staker must run both an execution client and a consensus client.
​

Ethereum.org's nodes-as-a-service page says solo stakers must run their own infrastructure rather than rely on third-party providers, and that since The Merge it is no longer possible to run only a consensus client against a centralized provider for execution data. Light nodes, by contrast, do not participate in consensus, per the nodes and clients page.
​

Ethereum has several independent client implementations written in different languages, which ethereum.org says makes the network stronger and more diverse. On Solana, Anza publishes the operator documentation for validators and RPC nodes. Client choice affects hardware needs, sync modes and which node types are available.
​

Requirements vary widely by chain and node type. On Ethereum, the archive node is the heavy case, with several terabytes of disk. Solana's published requirements are server-class, and an RPC node that indexes all accounts needs more memory than a validator.
​

Anza's Solana validator requirements list, as of October 2026, 12 cores and 24 threads or more and 256 GB of RAM for a validator, and 16 cores and 32 threads plus 512 GB of RAM for an RPC node serving all account indexes. Disks are PCIe Gen3 x4 NVMe or better, with at least 1 TB each for accounts and ledger and 500 GB for snapshots. An unstaked node needs a 1 Gbit/s symmetric connection; a staked node needs at least 2 Gbit/s. Setting up a Solana RPC node is documented separately in Anza's RPC node guide.
​

Node as a service means renting access to nodes that a provider runs, instead of operating your own. The provider handles syncing, upgrades and scaling, and developers connect through an API key. Most dApps start this way because running production nodes takes ongoing engineering time.
​

Per ethereum.org's nodes-as-a-service page, some services give each customer a dedicated managed node while others load-balance requests across shared nodes, and many include testnet access and archive data. The main benefit is not spending engineering time on node maintenance; the main cost is that it centralizes the infrastructure side of a product. Eco compares hosted options for stablecoin apps in Best Stablecoin RPC Node Providers.

Running a node gives independence but costs money and attention, and the lighter options trade away some of the verification that makes a node worth running. Hosted nodes remove the work but put a third party between your app and the chain.

No. Wallets and dApps usually connect to someone else's node over RPC, per Ethereum.org nodes-as-a-service docs.
​

A full node prunes old state; an archive node keeps every historical state, per Ethereum.org archive node docs.
​

A node cannot sign for you; ethereum.org notes node services should not store private keys, per its nodes-as-a-service page. A dishonest node can still return false data, which is why self-verification matters.
​

Public testnet RPCs are free; see Sepolia network settings and Solana devnet.
​

Node definitions and Ethereum requirements come from ethereum.org; Solana requirements come from Anza's documentation. All pages were fetched October 13, 2026. Hardware figures change with client releases; check the client's own docs before buying hardware.