Full Node
Node that fully verifies and stores blockchain state.
A full node is software that downloads blockchain data and independently verifies it against the protocol's consensus rules. It rejects invalid transactions and blocks rather than trusting another server's interpretation. Depending on the network and configuration, it stores current state plus some or all historical block data.
Full nodes differ from wallets, miners, and validators. A wallet manages keys and prepares transactions but may query a remote node. A validator or miner participates in block production and usually operates verification software. Running a full node alone generally does not earn protocol rewards, though it supports the network by relaying valid data and serving local applications.
Independent verification matters because third-party RPC providers can be unavailable, censor requests, log addresses, or return incorrect information. A self-hosted node lets a developer read state, broadcast transactions, and check balances under chosen software rules. It also improves privacy when queries no longer reveal the entire wallet history to one public service.
Node types vary. A pruned node verifies history but discards older data not needed for current operation. An archive node retains historical state for queries at past blocks and requires far more storage. Light clients verify selected commitments with lower resources but rely on additional assumptions for data retrieval. Terminology differs among chains.
Operating a full node requires fast storage, bandwidth, memory, CPU, power, monitoring, and updates. Initial synchronization can take substantial time. Exposing administrative or unrestricted RPC endpoints to the internet can allow abuse or resource exhaustion. Use firewalls, authentication, rate limits, and separate interfaces for trusted applications.
Operators should monitor peers, sync status, finalized checkpoints, disk growth, client health, and chain progress. Client diversity reduces correlated software failures. Back up validator keys, configuration, and irreplaceable metadata securely, while ordinary blockchain data can often be resynchronized. A full node strengthens verification and infrastructure independence, but it remains an actively maintained system rather than a one-time download.
Organizations should document ownership, patch schedules, capacity thresholds, and failover procedures. Regular restoration and resynchronization tests reveal whether the team can recover service without relying on one administrator's undocumented knowledge.
Public RPC traffic should remain isolated from internal signing, monitoring, and administrative interfaces wherever practical.
Frequently asked questions
- A full node independently verifies blocks and transactions instead of trusting a third-party RPC provider or explorer. It can improve privacy, provide reliable application data, enforce the operator's chosen consensus rules, and strengthen network resilience by relaying valid information. Running one does not automatically earn rewards, propose blocks, or make a weak application contract safe.
- Requirements depend on network, client, pruning mode, history retention, and expected API traffic. Plan for supported CPU architecture, sufficient RAM, fast storage with growth capacity, reliable bandwidth, power, and maintenance. Archive nodes require much more disk than pruned full nodes. Use official current client recommendations and leave capacity for database compaction, snapshots, and upgrades.
- Monitor synchronization, finalized height, peers, disk space, database performance, CPU, memory, network traffic, clock, and client logs. Apply verified security updates promptly while avoiding untested production changes. Use diverse providers or failover where uptime matters, protect RPC access, and alert on stalled blocks or peer loss. Back up keys and configuration, not replaceable chain data blindly.