A blockchain node is a computer or software instance that participates in a blockchain network by maintaining, validating, relaying or otherwise processing blockchain data according to the network's protocol. Nodes are fundamental to decentralised blockchain operation because they allow independent participants to verify information rather than relying on a single authoritative server. The exact capabilities of a node depend on the blockchain and node software.
Some nodes maintain extensive copies of blockchain data and independently verify blocks and transactions, while others retain less information or perform more limited functions. A node is therefore not synonymous with a miner or validator: mining and validation are specialised consensus-related activities, whereas many nodes simply verify and distribute data.
A full node generally downloads and verifies blockchain data according to the protocol's rules. It can independently check whether transactions are valid, whether blocks follow consensus requirements, whether state transitions are correct and whether cryptographic proofs are valid. This independent verification is important because a node does not have to trust the claims of another participant if it can validate the relevant data itself.
In an account-based system, this may involve maintaining a representation of current state, while in a UTXO system it includes tracking the information required to determine which outputs remain spendable. Full nodes therefore provide an important layer of verification and resistance to incorrect or fraudulent data being accepted merely because another participant transmitted it.
Nodes communicate through a peer-to-peer network. A node discovers or maintains connections with other nodes and exchanges information such as transactions, blocks and network metadata. When a valid transaction enters the network, nodes can relay it to peers, creating a distributed propagation system rather than requiring every participant to connect to one central server. The same general principle applies to newly proposed blocks. Network topology, bandwidth, latency, peer selection and software configuration affect how quickly information propagates. Nodes may reject malformed or invalid data before forwarding it, reducing the spread of information that does not comply with protocol rules.
Different blockchain systems use different categories and terminology. A full node normally verifies blockchain rules independently, whereas a light or simplified client may rely on other nodes for some information or proofs. An archival node can retain historical state or data that ordinary full nodes may prune or otherwise not keep in the same form. In proof-of-work networks, miners are specialised participants that perform the computational work required to propose blocks. In proof-of-stake networks, validators perform specialised duties such as proposing and attesting to blocks. A validator or miner generally operates blockchain node software, but running a node does not automatically make a machine a miner or validator.
Nodes contribute to decentralisation by creating multiple independent verification points. If only a small number of entities controlled all meaningful verification infrastructure, those entities could potentially exert greater influence over which information users receive or which protocol rules are enforced in practice. A diverse population of independently operated nodes makes it harder for one participant to unilaterally redefine valid transactions or blocks because other nodes can reject information that violates their chosen protocol rules. However, decentralisation is not simply a matter of counting nodes. Hardware requirements, geographical distribution, network connectivity, client diversity, hosting concentration and economic incentives can all affect the practical distribution of control.
Running a node can require substantial technical resources depending on the blockchain. Requirements can include storage capacity, memory, processor resources, bandwidth and a reliable internet connection. Some networks have relatively modest requirements, while others can involve significant storage and synchronisation demands. Operators may choose pruning or other storage-saving modes where supported. Node software must also remain compatible with network protocol changes, and operators need to consider security, backups, firewall configuration, key management if validator functions are enabled, and system monitoring. A node that is offline or misconfigured may fail to provide useful participation even though its software remains installed.
Nodes also provide users and applications with infrastructure for obtaining blockchain information. Wallets, explorers, exchanges, smart-contract applications and development tools may communicate with nodes through interfaces such as JSON-RPC. Publicly accessible node providers can offer this infrastructure as a service, but relying exclusively on a third-party provider reduces the user's direct control over data access and may introduce privacy, availability or censorship considerations. Running one's own node can improve verification independence and can reduce reliance on third-party infrastructure, although it requires additional resources and maintenance. This illustrates the distinction between using a blockchain and independently verifying a blockchain.
The defining characteristic of a blockchain node is participation in the network's distributed protocol environment. Nodes receive, validate, store and relay data according to their specific role and configuration, helping the network maintain a shared view of valid blockchain history and state. Consensus participants such as miners and validators are specialised examples within this broader ecosystem, while ordinary full nodes can contribute verification without receiving block rewards. The security and decentralisation properties of a blockchain therefore depend not merely on the existence of a ledger but on a network of independent software instances that enforce protocol rules, communicate with one another and reject invalid state transitions.
