What is a blockchain node?
A blockchain node is a running piece of software connected to a blockchain network that receives and processes data. Technically it is one actual run of a client program, which may sit on a home computer, a server or a cloud instance. A node is not a particular kind of dedicated hardware, and it does not necessarily represent one separate person or organization: a single computer can run several nodes, and the same operator can control several computers.
A node's core function is to process network data according to the protocol rules implemented by its local software. It may receive transactions and blocks, check whether data conforms to the protocol, store the ledger or current state, relay valid data to other nodes, and provide query interfaces to wallets and applications. Different nodes take on different tasks, so "node" cannot be equated directly with a miner, a validator or a server that stores all historical data.
How a node takes part in a transaction
From the moment a wallet sends a transaction to the point where the network accepts it, the process usually runs as follows:
- The wallet creates a transaction based on what the user does, and signs it using the appropriate authorization method.
- The wallet submits the transaction to the blockchain node it is connected to. That node first checks the applicable rules, such as format, signature, balance, transaction sequence number or spending conditions.
- Once the transaction passes those checks, the node can relay it to other nodes. Those nodes still validate it themselves rather than trusting it simply because the sender already checked it.
- Participants with block production duties can select content from pending transactions and assemble a candidate block.
- After other validating nodes receive the block, they check the block and the transactions it contains, and update the ledger state they store according to the consensus and fork choice rules.
A node receiving or relaying a transaction therefore does not mean the transaction is confirmed, and a producing node placing a transaction into a candidate block does not mean every node will accept that block. Each validating node reaches its result under the rules it runs, and the network then uses its consensus mechanism to settle the choice among valid candidates.
The four main jobs a node does
Connecting and syncing with other nodes
A node finds and connects to other nodes on the same network, obtaining new blocks, transactions or state information from them. A node that has just started also has to sync up to the network's current progress. The sync method determines where it begins validating, how much historical data it downloads and what it retains; the specifics vary by network and client software.
Checking network data independently
A validating node applies the protocol rules locally. It can check whether a transaction was properly authorized, whether the same asset has already been spent, whether a block's structure is valid, and whether the prior history a block references fits the fork choice rules. A node does not need the sender's agreement before rejecting invalid data.
This independent checking can only establish that data conforms to the protocol; it cannot establish that an offchain statement is true. If real-world information attached to a transaction was wrong to begin with, a node generally cannot detect that from onchain rules alone.
Storing the ledger and current state
A node may store blocks, transactions, account balances, unspent transaction outputs or smart contract state. The scope of storage depends on the network, the node mode and the intended use. Some nodes keep the data needed for current validation and delete older content; others additionally store historical state, which makes it possible to query the condition of an account or contract as of a past block.
Storing more data does not necessarily mean holding more consensus power. An archive service can answer more historical queries, but whether the network accepts a block is still determined by the protocol rules and the relevant consensus participation.
Providing interfaces to wallets and applications
Wallets, block explorers and decentralized applications usually need to query a node for balances, transaction status or block data, and they also submit signed transactions through a node. A node offering this kind of remote call interface is often called an RPC node, where RPC stands for "remote procedure call" — meaning other programs can have the node perform a query or submission through an agreed request.
Using a third-party RPC service is not the same as running your own node. In that case the provider may see where requests come from and what is being queried, and it may also return delayed, missing or incorrect data. Whether a wallet validates the returned result itself depends on the client and proof mechanisms it uses.
How common node types differ
"Full", "light", "archive", "validator" and "RPC" describe different dimensions; they are not a fixed ladder from low to high. One node can belong to several of these categories at once.
| Name | Main characteristic | What it does not imply |
|---|---|---|
| Full node | Independently validates the blocks and transactions it receives under network rules, and maintains the ledger or state needed to keep validating | Does not necessarily keep every historical state permanently from the genesis block |
| Light node or light client | Downloads less data and uses block headers, cryptographic proofs or other mechanisms to check information obtained from full nodes | Does not mean no validation at all, and does not guarantee the same data availability as a full node |
| Archive node | Beyond full validation, retains more historical blocks or historical state so it can answer queries about past points in time | Does not automatically gain more voting power, and is not necessarily responsible for producing blocks |
| Block-producing node | Runs mining, validator or other production components, and can take part in block proposal or confirmation under the protocol | Not everyone running a node can or needs to take on this role |
| RPC node | Provides wallets, applications or developers with interfaces to read data and submit transactions | "Providing an interface" alone says nothing about whether it fully validates or stores all history |
Different blockchains may define these names differently. For example, Bitcoin's node documentation calls a node that can download and validate blocks and then propagate data to other nodes a full node, while distinguishing archival nodes that retain complete history from pruned nodes that delete old blocks. Ethereum's node documentation instead distinguishes full, archive and light nodes, with an execution client and a consensus client together making up a current Ethereum node. When comparing nodes, confirm the specific network and software version first rather than relying on the name alone.
Nodes, clients, miners and validators
A client is the software that implements a blockchain protocol; a node is an instance of that client software running and connected to the network. Much as a browser is a category of software while the browser currently running on a particular computer is an instance, the two are related without being the same concept.
Miners and validators carry specific consensus duties. Miners on a proof-of-work network try to produce blocks that meet the requirement; validators on a proof-of-stake network may propose blocks or vote on them. An ordinary full node can validate blocks and reject data that breaks the rules even when it produces no blocks at all. On Ethereum, for instance, validator software is a consensus component that can be added alongside a node, and not every node syncing the network runs a validator.
A wallet, in turn, helps users manage authorization information, create transactions and interact with nodes. A wallet can connect to its own node or use a third-party node; the wallet interface, the node and consensus participants each do different work.
What running your own node does and costs
Running your own validating node reduces dependence on third-party data interfaces. The operator can check blocks and transactions under local rules, query local data directly, and avoid sending every address lookup to the same external RPC service. If the node accepts inbound connections or answers data requests, it can also supply network data to other participants.
The cost is storage space, network bandwidth, computing resources and ongoing maintenance. An operator has to select the right network, keep software updated, monitor sync status and protect administrative interfaces. Software defects, misconfiguration, disk corruption or losing connectivity to honest nodes can still leave local results wrong or behind.
Running a node also does not automatically earn block rewards. Whether you can propose blocks, vote or receive protocol rewards depends on the network's consensus mechanism, eligibility conditions and whether you run the corresponding components. A larger number of nodes helps reduce dependence on a few operators, but it does not automatically increase block capacity or transaction speed; those capabilities are also constrained by protocol and network design.
What a node can validate
What a node can validate are the digital conditions the protocol specifies, such as signatures, balances, transaction format and how blocks connect. It cannot determine on its own whether a private key was stolen, whether a user understood a transaction, whether a smart contract matches a user's intent, or whether an external data source reported a real event.
A node's judgement also depends on the rule version it runs and the network data it has seen. A protocol upgrade, a temporary fork, a software defect or network isolation can leave different nodes with different results for a time. "The node validated it" should therefore be read as "this node accepts it under its current rules and the data it has seen", not as proof of absolute correctness detached from those premises.
FAQ
Is every wallet a blockchain node?
No. A wallet may embed a node or a light client, or it may simply connect to a third-party RPC node. To tell the difference, look at whether the wallet runs a protocol client, which data it validates, and which external services it depends on.
Does a full node always store all historical data?
Not necessarily. "Full" usually emphasizes the ability to apply the complete validation rules independently; it does not necessarily mean retaining all historical state permanently. Some networks let a full node prune old data after validation, and querying arbitrary historical state may require an archive node.
Do more nodes make transactions faster?
Not necessarily. More independent nodes can improve a network's redundancy and resistance to single points of failure, but every node still has to receive and validate data. Transaction throughput and confirmation speed are determined mainly by rules such as block capacity, how blocks are produced, consensus and network propagation.
Does running a node mean mining or earning staking rewards?
Not as a general rule. An ordinary node can simply sync, validate and relay data. Mining or validator duties usually also require specific software, hardware, a stake or other protocol conditions.
Are the node counts shown online accurate?
They are usually only estimates. Nodes may sit behind a router, firewall or private network and not accept public connections, and the same operator may run several nodes. A network crawler can only see the portion of nodes it is able to discover and connect to.
Related concepts
Continue with blockchain, block, crypto wallet and cryptographic hash, or return to the Crypto Glossary.
Sources
- NISTIR 8202: Blockchain Technology Overview — general terminology for nodes, full nodes, lightweight nodes and blockchain networks.
- Bitcoin Developer Guide: P2P network — full nodes, archival nodes, pruned nodes and the propagation of transactions and blocks.
- Bitcoin Developer Guide: operating modes — the difference between full validation and simplified payment verification clients.
- Ethereum.org: nodes and clients — clients, full nodes, archive nodes, light nodes and sync methods.
- Ethereum.org: node architecture — the division of labour between execution clients, consensus clients, validators and RPC interfaces.
- Ethereum.org: light clients — how light nodes obtain data, the scope of their validation and their external dependencies.
© 2025 OKX. Niniejszy artykuł może być powielany lub rozpowszechniany w całości, a także można wykorzystywać jego fragmenty liczące do 100 słów, pod warunkiem że takie wykorzystanie ma charakter niekomercyjny. Każde powielanie lub rozpowszechnianie całego artykułu musi również zawierać wyraźne stwierdzenie: „Ten artykuł jest © 2025 OKX i jest używany za zgodą”. Dozwolone fragmenty muszą odnosić się do nazwy artykułu i zawierać przypis, na przykład „Nazwa artykułu, [nazwisko autora, jeśli dotyczy], © 2025 OKX”. Niektóre treści mogą być generowane lub wspierane przez narzędzia sztucznej inteligencji (AI). Nie są dozwolone żadne prace pochodne ani inne sposoby wykorzystania tego artykułu.
