What is a Blockchain Node? The Developer’s Guide
Most guides about blockchain nodes are written for people who want to run one and earn rewards. This one is written for developers who need to understand what a node is, how their application connects to it, and what that means for the infrastructure choices they make when building on-chain.
What is a Blockchain Node?
A blockchain node is a computer running blockchain software that participates in a decentralized network by storing, validating, and propagating transactions. Every blockchain interaction your application makes (every balance check, every transaction, every contract call) goes through a node.
Nodes are the infrastructure layer that makes a blockchain network work. There is no central server. There is no single database. The blockchain is a network of thousands of nodes that each hold a copy of the ledger and constantly synchronize with each other.
When your dApp sends a request to “read the current ETH balance of a wallet”, that request goes to a node. When you submit a transaction, that transaction is broadcast through a node to the rest of the network. Nodes are not optional infrastructure. They are the blockchain.
What Does a Blockchain Node Actually Do?
A node performs four core functions:
1. Validates transactions When a transaction is broadcast to the network, every full node independently checks whether it is valid: correct signature, sufficient balance, proper format. Invalid transactions are rejected before they can be included in a block.
2. Stores the blockchain Full nodes store a complete copy of the entire blockchain history. Every block, every transaction, every state change. This is what enables trustless verification: no single entity controls the ledger.
3. Propagates data When a new block is produced, nodes relay it to their connected peers. Your node receives it, validates it, and passes it on. This is how the network stays synchronized without a central coordinator.
4. Exposes an RPC interface
This is the part that matters most for developers. Every Ethereum node exposes a JSON-RPC API that your application can call. eth_getBalance, eth_sendRawTransaction, eth_call: these are function calls made directly to a node over HTTP or WebSocket. The node processes the request against its local copy of the blockchain state and returns the result.
When you connect your dApp to an RPC endpoint, you are connecting to a node. The endpoint URL is simply a gateway to a node (or a cluster of nodes) that responds to your JSON-RPC calls.
Types of Blockchain Nodes
Not all nodes are equal. The type of node your application connects to determines what data you can access and how.
Full Node
A full node stores the complete current state of the blockchain and enough history to validate new blocks. It can answer all standard JSON-RPC queries: balances, transactions, contract state, recent blocks.
Full nodes are what most RPC providers run. They handle the vast majority of production dApp queries.
Answers queries like:
eth_getBalance: current balance of any addresseth_call: read any contract’s current stateeth_getTransactionReceipt: get receipt for any recent transactioneth_blockNumber: get the current block height
Light Node
A light node stores only block headers, not full transaction data. It relies on full nodes for data it does not have locally. Light nodes are designed for resource-constrained environments (browser wallets, mobile apps) and are not suitable for serving application RPC traffic.
As a developer: you will not run a light node for your application. You connect your application to a full node.
Archive Node
An archive node is a full node that also stores every historical state at every block height. This allows queries like “what was the balance of this address at block 10,000,000?”, something a standard full node cannot answer because it prunes historical state data.
Archive nodes are significantly more expensive to run:
- 12TB+ of storage vs 2TB+ for a full node
- Growth rate is faster
- Syncing from scratch takes weeks
As a developer: you need archive access if your application queries historical state beyond what a full node retains. Typical use cases are analytics platforms, forensics tools, and DeFi protocols that need deep historical position data. Most dApps do not need archive access.
Validator Node
A validator node participates in consensus, proposing and attesting to new blocks on Proof-of-Stake networks like Ethereum. Validators are required to stake ETH (32 ETH per validator on Ethereum mainnet) and are subject to slashing penalties for misbehaviour.
As a developer: validator nodes are not part of your application architecture. They are separate infrastructure operated by stakers and protocols. Your application connects to full nodes, not validators.
The RPC Connection: How Your Application Talks to a Node
Every Ethereum node exposes a JSON-RPC API. JSON-RPC is a lightweight protocol that lets your application call functions on the node as if they were local function calls.
# Your application asking a node for the current ETH balance
curl -X POST https://eu.endpoints.matrixed.link/rpc/ethereum?auth=YOUR_KEY \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "eth_getBalance",
"params": ["0xYourWalletAddress", "latest"],
"id": 1
}'The node receives this request, looks up the balance in its local state database, and returns the result. Your application never needs to know how the blockchain works internally. It just calls methods.
This same pattern works across every EVM-compatible chain: Ethereum, Arbitrum, Base, Polygon, Optimism, Avalanche. Same method names, same JSON-RPC format, same response structure. Only the endpoint URL changes.
HTTP vs WebSocket:
Nodes expose their RPC over two transports:
- HTTP: Request-response. Best for one-off queries (balance checks, contract reads, transaction submission).
- WebSocket: Persistent connection. Required for subscriptions: watching for new blocks, monitoring pending transactions, listening for contract events.
// WebSocket subscription — receive a push notification on every new block
const ws = new WebSocket('wss://eu.endpoints.matrixed.link/ws/ethereum?auth=YOUR_KEY');
ws.on('open', () => {
ws.send(JSON.stringify({
jsonrpc: '2.0',
method: 'eth_subscribe',
params: ['newHeads'],
id: 1
}));
});For a deeper comparison of when to use each, see: WebSocket vs HTTP for Blockchain RPC
Full Node vs Archive Node: What Your Application Actually Needs
Most developers do not need archive access. Here is how to determine which you need:
| Query Type | Full Node | Archive Node |
|---|---|---|
| Current wallet balance | ✅ | ✅ |
| Current contract state | ✅ | ✅ |
| Recent transaction receipts | ✅ | ✅ |
| New blocks / pending txs | ✅ | ✅ |
| Historical balance at specific block | ❌ | ✅ |
| Historical contract state at any block | ❌ | ✅ |
eth_getLogs across thousands of blocks | Partial | ✅ |
| On-chain analytics, DeFi forensics | ❌ | ✅ |
Default choice: Full node. It handles the RPC methods used by the overwhelming majority of production dApps.
Choose archive when: Your application queries historical blockchain state at arbitrary block heights. If you are unsure, start with full node access. You will hit errors on historical queries if you need archive, and can upgrade then.
Running Your Own Node vs Using an RPC Provider
Understanding what a node is naturally leads to the question: should you run your own, or connect to a managed provider?
The short version:
-
Running your own node gives you full sovereignty and privacy. It also costs $225–$455+/month in real terms (hardware plus developer maintenance time), takes 3–7 days to sync from scratch, and requires ongoing engineering attention.
-
Using a managed RPC provider gives you instant access across 22+ networks, zero maintenance, redundant infrastructure, and predictable pricing starting at $49/month.
For most development teams, the trade-off is clear. For protocol-level infrastructure or strict data sovereignty requirements, running your own node may be the right call.
For the full breakdown with cost tables: Run Your Own Ethereum Node vs RPC Provider
FAQ: Blockchain Nodes
What is the difference between a blockchain node and an RPC endpoint?
A blockchain node is the server running the blockchain software. An RPC endpoint is the URL your application uses to send requests to that node. When you use a managed RPC provider, the endpoint URL connects you to a node (or cluster of nodes) operated by the provider. The node does the work; the endpoint is just the address.
Does my dApp need its own blockchain node?
No. Most dApps connect to a managed RPC provider rather than running their own node. Running your own node is expensive, time-consuming to set up, and requires ongoing maintenance. Managed providers handle the infrastructure so your team can focus on building the application.
What is the difference between a full node and an archive node?
A full node stores the current state and enough history to validate new blocks. An archive node stores every historical state at every block height, enabling deep historical queries. Most dApps need a full node. Analytics platforms, forensics tools, and some DeFi protocols need archive access.
Can a blockchain node go down?
Yes. A single self-hosted node is a single point of failure. If the server goes down, your application loses access. Managed RPC providers run redundant nodes with automatic failover, reducing this risk significantly.
What chains does each node support?
Each node supports exactly one chain. An Ethereum node only serves Ethereum. To access Arbitrum, you need an Arbitrum node. To access Polygon, you need a Polygon node. This is why multi-chain applications either run many nodes (expensive) or use a provider that covers multiple chains under one account.
How do I connect my application to a blockchain node?
Point your Web3 library at an RPC endpoint URL. For example, using ethers.js:
const { ethers } = require('ethers');
const provider = new ethers.JsonRpcProvider(
'https://eu.endpoints.matrixed.link/rpc/ethereum?auth=YOUR_KEY'
);
const balance = await provider.getBalance('0xYourAddress');Replace the endpoint URL with the network you need. BoltRPC uses the same format across all 22 supported networks.
Conclusion
A blockchain node is the server your application is actually talking to when it makes any on-chain interaction. Every JSON-RPC call (balance check, transaction submission, contract read) goes through a node.
As a developer, you have two options: run your own node, or connect to a managed RPC provider. For most teams, a managed provider is faster, cheaper, and lets you focus on the product instead of infrastructure.
BoltRPC provides access to 20+ blockchain networks over HTTP and WebSocket, with ISO/IEC 27001:2022 certified infrastructure via Matrixed.Link. Trusted by Chainlink, Tiingo, Gains Network, Enjin. Processing 2 billion RPC calls daily.
Start your free 2-week trial, no credit card required: trial.boltrpc.io
Explore all supported networks: boltrpc.io/networks