A blockchain node is a device or process that runs a protocol client and connects to the network. Nodes may propagate transactions, validate blocks, store the ledger, or provide query services. Full, light, and archive refer to different approaches to data storage and validation.
Nodes, miners, and validators are not interchangeable terms. Block producers propose blocks, while ordinary full nodes can independently reject data that violates consensus rules even if they do not produce blocks themselves.

A full node downloads and validates the blocks and transactions required by the protocol, building a local view of the valid chain from the genesis block or a trusted synchronization point. It checks data against the consensus rules implemented by its local client instead of treating responses from third-party interfaces as facts.
“Full” primarily describes validation capability and does not necessarily mean permanently retaining every historical state. Some networks support pruning: after validating data, a node deletes older block data to save disk space while retaining the information needed for continued validation.
Light nodes generally store only block headers, state commitments, or smaller proof data, then request relevant transactions and proofs from full nodes. They may be able to verify that a record was committed by a particular block, but may not independently verify every transaction rule or data availability condition.

Light nodes are suitable for mobile devices and resource-constrained environments, but their security depends on the protocol design, the number of connected nodes, and the types of proofs used. If a client trusts a single remote RPC endpoint without verifying any proof, it is closer to a remote service client and should not automatically be described as a light node.
In addition to performing full validation, an archive node retains historical states or data that can quickly reconstruct historical queries. For example, an ordinary full node may not directly retain an account balance at a very old block height, while an archive node can provide it immediately.
The meaning of “archive” differs across networks. On some networks it means retaining all original blocks; on others it means retaining every historical state. To determine a node’s actual capabilities, review the client’s synchronization mode and available interfaces rather than relying on the name alone.
| Comparison | Full node | Light node | Archive node |
|---|---|---|---|
| Independent validation | High; validates on-chain data according to protocol rules | Limited; depends on block headers and proof design | High; usually includes full validation capability |
| Historical data | May be retained in full or pruned | Stores only limited summaries and relevant data | Retains more complete historical state |
| Disk and synchronization cost | Medium to high | Low | Highest |
| Common uses | Wallet backends, independent validation, network relay | Mobile and resource-constrained clients | Block explorers, data analysis, historical queries |
Individuals who value independent verification can run a full node. Applications that need only a small amount of state may evaluate light clients or multiple RPC providers. Block explorers and on-chain analytics services often require archive data and additional indexing. Actual resource requirements vary by network, client, and synchronization method.
A client is software that implements the protocol, such as an execution client or consensus client. A node is an instance that runs this software and connects to the network. A miner or validator is a role that participates in block production and confirmation under a particular consensus mechanism.
A validator usually requires node software, but not every node is eligible to be a validator. One physical server may also run multiple node processes, while a cloud node provider may centrally control many access points.
Running a node can reduce dependence on third-party data services, make transaction and balance queries more verifiable, and contribute connections for network propagation. It does not automatically earn block rewards; rewards depend on participation in consensus and the applicable protocol rules.
Node operators must manage storage, bandwidth, software upgrades, ports, and key isolation. Public RPC endpoints may also be abused, so management interfaces should not be exposed directly to the internet. When protocol upgrades diverge, nodes may follow different rules; see Soft Forks vs. Hard Forks for the underlying principles.
To learn how nodes validate transactions and receive blocks, continue with How Blockchain Works. For the broader context, return to What Is Blockchain?.
Usually, holding tokens is not required merely to validate the chain. Becoming a proof-of-stake validator may require staking assets or meeting protocol-specific eligibility requirements. Running an ordinary full node and participating in staking are separate activities.
Not necessarily. You must also consider who controls the nodes, how they are distributed across regions and cloud providers, which clients they use, and whether validation power is concentrated. A large number of nodes controlled by the same entity does not provide the same degree of independence.
No. Asset state is recorded on the network ledger, and control comes from your keys. Shutting down a node only stops local synchronization and services; the on-chain view can be restored after the node synchronizes again.
No. An archive node stores public historical state defined by the protocol. It does not store private keys, wallet passwords, or deleted files from a user’s device.


