Every Web3 product needs to read a blockchain data. A crypto wallet can fetch a balance and a nonce before signing a transaction, or DEX uses end calls like `eth_call` to pull pool reserves. Or look at a payment processor: it watches addresses for deposits, while an analytics dashboard replays historical state block by block.
All of that data comes from servers with nodes. So what are nodes in blockchain networks? They are set up servers that run a chain’s client software with blockchain data. They are checking every new block against the protocol rules, and pass valid data on to peers.
Some nodes also expose an RPC interface, which lets applications query the chain and broadcast transactions. The sections below cover how nodes verify data, how the main node types differ, what each way of connecting costs, and a working Ethereum request through NOWNodes.
Key Points:
– Main function: A blockchain node stores data of the network. It also views blocks, transactions, and other information based on the type of the node itself.
– Usage: User can run own node, use a public endpoint or rent a shared/dedicated plan from the RPC Provider.
– Use cases: Crypto Wallets can check balances, Dexes can track deposits, and explorers can index blocks.
What are Blockchain Nodes and how do they work?
A node is a computer which contains downloaded blockchain information. It also stores the ledger and checks every new block using the protocol rules before relaying it. Each node verifies blocks on its own to prevent the inclusion of an invalid block in the chain. Therefore, the information contained within a block cannot be incorrect or untrue.

What does it mean in technical terms? It is a client software or a machine with enough disk space to sync the blockchain history. For example, Ethereum splits that software into an execution client such as Geth or Reth and a consensus client that works as a pair. A transaction then travels through nodes in a fixed order:
1. While a wallet signs the user transaction, this information is sent to the node.
2. The node checks the correctness of signature and nonce. After it confirms that sender can cover the fee, and gossips the transaction to its peers.
3. A miner or validator nodes checking transactions within mempool and includes it in a proposed block.
4. If a rule has been violated, all other nodes re-execute the block and reject it.
5. Provided that the transaction is confirmed, the nodes that have accepted the block update their local state.
The fourth stage is crucial to blockchain security. It is this stage that ensures the independence of the verification process. It should be understood that while miners and validators merely propose blocks, every full node independently processes and applies the rules of the network in which a transaction took place. This allows the operators of such nodes to verify the blockchain without relying on third-party services—such as block explorers.
Let’s look at a more technical example involving JSON-RPC. Through this interface, a node handles requests from applications. This is accomplished using a set of methods, which can be found in the network’s own documentation. For example, methods such as `eth_getBalance` and `eth_call` allow you to retrieve specific data, depending on your objectives. Meanwhile, `eth_sendRawTransaction` enables the submission of signed transactions. This is precisely how cryptocurrency wallets and application backends interact with the blockchain.
What node types exist, and who needs each one?
Nodes can be classified into eight main types, depending on their specific functions, the amount of data they store, and their role in the consensus process. The table outlines key metrics for these node types within the context of the most prominent networks: Ethereum and Bitcoin.
| Node type | What it keeps | Role in consensus | Who using mostly |
| Pruned full node | Recent blocks and current state | Validates, cannot serve old blocks | Wallet and payment backends |
| Archive full node | Every historical state | Validates, serves full history | Explorers, security analysts |
| Light node | Block headers | Verifies proofs, relies on full nodes | Mobile wallets |
| Mining node | Full chain plus block templates | Proposes proof-of-work blocks | Miners and pools |
| Validator node | Full chain plus signing keys | Proposes and attests in proof of stake | Stakers |
| Masternode | Full chain plus collateral | Extra services, no mining | Collateral holders |
| Lightning node | Channel state plus a Bitcoin node | Routes off-chain payments | Merchants, payment services |
| Authority node | Full chain | Approved validator in proof of authority | Consortium members |
Full nodes
Full nodes download every block and validate it independently. The two variants differ in what they retain afterward:
Pruned full nodes delete old block data once it is verified. Bitcoin Core’s `prune` setting goes as low as 550 MiB, which keeps at least the last 288 blocks BIP 159. Wallet backends and payment services that need only current state usually run this variant.
Archive full nodes keep every historical state from zero block. This is a very heavy node and needs a huge disk space. For example, Ethereum archive nodes need from about 2 TB to over 12 TB depending on the client. Block explorers and security analysts rely on them, along with anyone who asks for an account’s balance at a past block.
Light nodes
Light nodes store only block headers. If full information is required, one must query full nodes and then verify that the data received matches these headers.
In the Ethereum network, modern light clients rely on the Proof-of-Stake consensus mechanism. Every 256 epochs (approximately once every 27 hours), the Beacon Chain—the core chain in Ethereum’s Proof-of-Stake system—forms a “sync committee” consisting of 512 validators. Their collective digital signature on each new block header allows a light client to determine exactly which block has been accepted by the network. The Helios protocol, developed by a16z, operates in precisely this manner: it synchronizes in about two seconds, requires no data storage space, and launches a local RPC interface on port 8545, to which a wallet can connect.
Mining nodes
Even those not well-versed in blockchain have likely heard the term “miners.” These are the entities that deploy mining nodes to earn rewards for successfully discovering a block within the network. This is often done by individual operators or so-called “mining farms.” By utilizing server-grade computing power, they capture blockchain transactions and validate them. In the Bitcoin network, for instance, mining pool software requests a block template from a node via an RPC call known as `getblocktemplate`. The mining hardware then performs hashing on this template until a valid “proof of work” is generated.
Validator nodes
Validator nodes propose and attest to blocks with staked collateral in place of hash power. On Ethereum, activating one takes 32 ETH plus an execution client and a consensus client running together. Staking operators fit this role, and running the same keys on two machines gets a validator slashed. Holders with less than 32 ETH typically stake through a pooled protocol instead.
Masternodes
Unlike a standard node, a masternode offers additional features, (such as the ability to accelerate transaction confirmations) but requires a substantial, fixed amount of coins to be held as collateral. Depending on the specific network, it is also frequently referred to as a “supernode” or a “validator.” Unlike a mining node, a masternode does not construct blocks from scratch; instead, it receives a fixed share of the block reward for every block.
Lightning nodes
Lightning nodes operate on top of full nodes—for instance, those of the Bitcoin network—and manage payment channels. In this scenario, transactions take place off the main blockchain. Only the opening and closing of channels are recorded on the Bitcoin blockchain itself. Payments are routed through a chain of channels using Hashed Time-Lock Contracts (HTLCs). Nodes that facilitate this routing earn a fee for forwarding the funds.
Payment services, meanwhile, use them to process a large number of small Bitcoin payments. This is the primary factor that acts as a constraint on liquidity, since a node can only execute a transaction up to the amount available within its channels.
Authority nodes
Authority nodes are validators in a network that operates on the Proof-of-Authority consensus mechanism. In such a system, blocks are created by a fixed set of trusted blockchain participants. Consider, for instance, the QBFT protocol used in Hyperledger Besu; it is well-suited for scenarios where the participants know one another. This protocol requires at least four validators, and block finalization occurs instantaneously, which eliminates the possibility of forks.
Consortiums and enterprise networks use this model for predictable block production. Let’s look at the BNB Smart Chain. It employs a hybrid mechanism known as Proof of Staked Authority. This mechanism allows for the integration of staking capabilities alongside a limited set of validators.
Options for connecting to a node

There are three common ways to connect to a node: you can deploy your own node, connect to a public node, or purchase a dedicated node from a node provider.
| Option | Setup | Approx. cost | Main drawback | Best for |
| Own node | Hardware, client install, initial sync | 140–300 per month (Ethereum full node, bare metal); 100–450 upfront (pruned Bitcoin node, home) | Upgrades, monitoring, disk growth | Exchanges, validators, privacy-critical teams |
| Public endpoint | None | Free | Rate limits, no uptime commitment | Prototypes and scripts |
| Shared provider plan | API key | Free tier, then paid plans by request volume | Plan-based request limits | Most dApps, wallets, and bots |
| Dedicated provider node | Arranged with the provider | On request | Higher cost than shared access | High-traffic production |
Running your own node
To set up your own node, you need to find out what hardware resources are required and how to go about the deployment. The documentation for almost any Blockchain Network includes the specifications required for its deployment. You can also find instructions there on how to run your own node. It is important to understand that this approach requires resources—both in terms of time and money.
Ethereum org’s guidance for an Ethereum full node, based on EIP-7870, is a fast CPU with 4+ cores, 32 GB of RAM, a 4 TB NVMe SSD, and about 50 Mbit/s of download bandwidth. Archive nodes need more disk, and their initial sync can take up to a month on an average consumer computer. For example, Cherry Servers prices bare-metal Ethereum nodes from $140 to $300 a month for an entry-level full node up to $800 to $1,500 or more for high-spec clusters.
If you need a single node that won’t be handling a high volume of requests, and you have the capacity to maintain it yourself, then this could be an option. However, keep in mind that beyond just setting it up and connecting it, you will also be responsible for performing updates and monitoring for any downtime.
Using a public endpoint
This is the most accessible connection option. Public RPC endpoints are available to anyone on the internet—often, they do not even require an API key. This method is frequently used for prototypes and small startups with a limited user base. However, there are several nuances to consider when choosing this as your primary connection method. Such nodes often impose strict limits on the number of requests per second (RPS), which can affect service performance during periods of peak load.
An important nuance is that public nodes are often used by a large number of people, which creates a risk of instability due to the load. Furthermore, public nodes are typically available only for common configurations; finding something more specialized elsewhere on the internet can be quite difficult.
Node Provider
A node provider handles blockchain infrastructure management, including network updates, maintenance, monitoring, and more. Much like using public nodes, this approach eliminates the need for significant time and effort spent on server configuration. However, the key differences, compared to public nodes, lie in the specific limitations, the range of services offered, performance, reliability, and access controls.
Node providers typically offer several connection options, the most common being Shared Nodes and Dedicated Nodes.
A Shared Node is a service that allows multiple customers to access a provider’s blockchain infrastructure using API keys or other authentication methods. In this model, the terms of access depend on the specific plan purchased, covering factors such as monthly RPC request limits, requests-per-second (RPS) limits, available RPC methods, and supported blockchain networks. This type of service is frequently used by projects that want to avoid the hassle of maintaining their own nodes while benefiting from managed infrastructure and authenticated API access. Shared Nodes are suitable for development, testing, and production applications with huge traffic.
If a project requires dedicated resources and greater infrastructure isolation, it can take a Dedicated Node. As with shared nodes, the provider remains responsible for ensuring the node stays operational. However, dedicated nodes offer expanded capabilities, including more consistent performance, potential access to additional RPC methods, and custom configurations. Depending on the provider, dedicated nodes may also operate without predefined RPC request quotas or RPS limits, although actual throughput depends on the allocated hardware and network conditions.
Mohammad Zahwy, CBDO at NOWNodes, explains why the choice deserves more attention than it usually gets:
Which setup fits your project?
To determine which connection option you need, consider your specific requirements:
1. What kind of project are you working on?
2. What is your projected traffic volume?
3. What is your budget?
4. How many networks do you need, and which ones?
5. Do you need to manage the node’s settings, updates, and software yourself?
6. Do you require any custom configurations (e.g., archive nodes, trace/debug methods, etc.)?
Once you have assessed your resources and needs, the right choice will become clear. If you simply want to test a prototype, connecting to public nodes is sufficient. If you have a low-load project but still want to manage the node’s settings yourself, you could deploy it on your own. However, if your project is large-scale, involves high traffic, and you prefer not to dedicate human resources to monitoring critical nodes, then shared nodes are the best option.
FAQ
What is a node in cryptocurrency?
In simple terms, a cryptocurrency node is a computer running blockchain client software. It stores network data, validates new blocks, and interacts with other nodes.
Can you run a blockchain node yourself?
Yes. You can refer to the official, publicly available documentation for various networks. It will contain information on network specifications, as well as step-by-step instructions.
Are blockchain nodes the same thing as miners?
No. A miner is a specific type of node operator who also performs the work of validating transactions (in a Proof of Work system). While a miner does operate a node, most nodes are not involved in mining.
How do you decide whether to use an archive node or a pruned node?
If you need historical data going all the way back to the genesis block, use an archive node. If that level of detail isn’t necessary, a pruned node will suffice. An archive node answers that request because it keeps every historical state.
How costly is it to run your own node?
A small pruned Bitcoin node at home costs $13 to $50 a year in electricity after the hardware purchase. High-spec Ethereum RPC clusters on bare metal reach $800 to $1,500 or more per month, before engineering time.



