A full node enforces the protocol’s rules for itself, which is the practical meaning of “don’t trust, verify.” Its client decides how much history it keeps: state pruning discards old state data, while history pruning trims old block bodies and receipts, and the two are configured separately. So “full node” describes a family of configurations, not one fixed footprint.<\/p>\n\n\n\n
It’s also worth correcting a common myth. A modern full node does not re-execute every block from the genesis block on first sync \u2014 Geth’s default snap sync downloads a recent state snapshot and verifies forward from a trusted checkpoint, as described in Geth’s sync-modes docs<\/a>. Full validation of the canonical chain still happens; it just doesn’t mean sequentially executing all of history during initial sync.<\/p>\n\n\n\n Storage depends on the execution client, consensus client, sync mode, pruning, and retained indexes, so treat any single number with caution. As a planning baseline, Geth’s hardware guide<\/a> recommends a 2 TB+ SSD, and real-world occupied space varies widely across clients and configurations \u2014 which is why a storage comparison should name the setup it measured.<\/p>\n\n\n\n Full nodes fit the largest group of operators \u2014 wallets, dApp backends, and individuals who want to validate independently. A full node lets you broadcast signed transactions through the node and read current state directly; it does not “write” to chain state, since only consensus produces new state. For most projects that don’t need deep history, this is the sensible default.<\/p>\n\n\n\n Archive node (Ethereum):<\/strong> a full node configured to retain historical state \u2014 account and contract values at past blocks \u2014 so it can serve historical-state queries without re-executing the chain. On Geth’s modern path-based scheme, the retained range is configurable.<\/p>\n\n\n\n An archive node answers a question like “what was this contract’s storage at block 12,000,000?” directly, instead of reconstructing it. That capability powers explorers, analytics, and tooling that reads deep history. On modern Geth, though, “archive” isn’t all-or-nothing: path-based archive mode<\/a> supports configurable state-history retention, and only a configuration that keeps the entire range provides complete historical state from genesis.<\/p>\n\n\n\n The storage cost is real and worth stating precisely. Per Geth’s documentation, a path-based archive retaining full flat state history needs roughly 2 TB, while storing flat states together with historical trie data can require around 6.5 TB, and a path-based archive sync can take on the order of two weeks. More storage-efficient clients such as Erigon exist, but published footprints vary by version and flags, so confirm against a current official benchmark before provisioning.<\/p>\n\n\n\n One nuance: archive state is needed specifically for queries about historical account or contract state beyond a node’s retained window. Old block bodies, transactions, and receipts can still be available on a non-archive node, so not every historical call requires an archive. Tracing is similar \u2014 whether a Here’s the full node vs archive node distinction in one line: a full node serves current state, an archive node also serves retained historical state. Both apply the same consensus rules, and both can independently validate the chain when correctly configured \u2014 the primary difference is retained historical state, not validation rules. A full node can still report today’s value of any address; it just may not hold that address’s value from 400,000 blocks ago.<\/p>\n\n\n\n Can a full node reconstruct that old value? Sometimes \u2014 but qualify it by client and retained data. Rebuilding historical state can require extensive re-execution, a resync, or data the node no longer holds, and it isn’t exposed as an automatic fallback for every query. That gap is the heart of the archive node vs full node difference: an archive setup pays for storage up front so historical reads are immediate.<\/p>\n\n\n These categories travel poorly across chains, so it’s worth being explicit. Bitcoin has no separate “archive node” mode in the Ethereum sense; a Bitcoin full node validates the entire chain during initial sync, and a pruned Bitcoin node is still a fully validating node that simply deletes older raw block and undo data afterward. Pruning there is a disk-management setting, not a downgrade in validation.<\/p>\n\n\n\n Bitcoin’s chain data is time-sensitive, too. It stood at roughly 753 GB as of July 2026 per YCharts<\/a>, growing about 6\u20137 GB a month, so recheck the current figure near publication. A pruned node can cut stored block data sharply by setting a prune target, but that target is only the block-file budget \u2014 the chainstate (the UTXO set), any optional indexes, and operating overhead sit on top, so the total footprint is larger than the prune number alone.<\/p>\n\n\n\n Light node \/ light client:<\/strong> a node that does not store or execute the full chain. On Ethereum it tracks authenticated consensus headers and requests execution data and proofs on demand, verifying them cryptographically. (“Light node” and “light client” are used interchangeably.)<\/p>\n<\/blockquote>\n\n\n\n A light client is the minimalist option, but it isn’t just a chain of proof-of-work headers like an early Bitcoin SPV client. On Ethereum it follows the beacon chain’s authenticated consensus updates and asks full or archive nodes for specific execution data and proofs when a user needs them, then checks those proofs against what it has verified. That’s what lets a mobile wallet confirm a payment without downloading hundreds of gigabytes.<\/p>\n\n\n\n The mechanism behind this is the sync committee. Ethereum selects a 512-validator sync committee every 256 epochs, approximately 27 hours, and those validators sign recent headers for light clients to verify. A light client still relies on a recent trusted checkpoint under Ethereum’s weak-subjectivity model and depends on providers or peers for data availability, even as it verifies the cryptographic proofs itself. As a performance example, a16z reports its Helios<\/a> client syncing in about two seconds under its tested conditions \u2014 a Helios figure, not a guarantee for every device or provider.<\/p>\n\n\n\n Implementations differ in maturity rather than sharing one readiness label; Ethereum’s light-client docs<\/a> list several projects at different stages of development. The tradeoff is scope, not blind trust: a light client verifies the consensus and state relevant to its requests, but it does not download and execute every transaction or maintain the full state. For end-user apps where footprint and speed matter most, that’s a reasonable trade \u2014 which is why light clients tend to power wallets rather than exchange backends.<\/p>\n\n\n The table below summarizes the storage, validation, and common uses of each node type. Figures are Ethereum-specific and depend on client, sync mode, and pruning, so read them as ranges to verify rather than fixed values.<\/p>\n\n\n\n Match the node to the question your app asks most often. If you mainly validate and broadcast against current state, a full node is the balanced pick. If your product sells history \u2014 a block explorer, an analytics tool, historical-state APIs \u2014 budget for an archive configuration and its storage. And if you’re shipping a mobile or lightweight client, a light client keeps the install tiny.<\/p>\n\n\n\n One caution: node type alone doesn’t describe a production architecture. Exchanges and other high-traffic services usually layer in redundancy, indexing, high availability, and sometimes archive access, rather than running a single node of any one type. Treat it as one decision inside a larger infrastructure design.<\/p>\n\n\n There’s also the question of whether to run the hardware yourself. Plenty of builders argue you always should. Ethereum co-founder Vitalik Buterin made that case bluntly in a March 15, 2026 post on X<\/a>:<\/p>\n\n\n\n “running a node is this oh so scary devops task that it is ok to leave to professionals. IT IS NOT… Running your own Ethereum infrastructure should be the basic right of every individual.”<\/p>\n<\/blockquote>\n\n\n\n![\"\"](\"https:\/\/nownodes.io\/blog\/wp-content\/uploads\/2025\/10\/fullnode1-1024x683.png\")
<\/figure>\n\n\n\ntrace<\/code> call works depends on the client, method, retained history, and re-execution limits, and some recent transactions can be traced without a full archive.<\/p>\n\n\nThe Core Difference<\/h2>\n\n\n
How the Labels Map to Bitcoin and Other Networks<\/h2>\n\n\n
\n
![\"\"](\"https:\/\/nownodes.io\/blog\/wp-content\/uploads\/2025\/10\/fullnode-1024x683.png\")
<\/figure>\n\n\n\nKey Differences<\/h2>\n\n\n
Feature<\/th> Full node<\/th> Archive node<\/th> Light node<\/th><\/tr><\/thead> Data retained<\/td> Current state; some history by config<\/td> Historical state (retention configurable)<\/td> Authenticated headers; proofs on demand<\/td><\/tr> Historical-state queries<\/td> Limited; may need re-execution or resync<\/td> Direct, within retained range<\/td> Limited; depends on external providers<\/td><\/tr> Validation<\/td> Independent, when configured correctly<\/td> Independent, when configured correctly<\/td> Verifies proofs and consensus updates<\/td><\/tr> Storage (Ethereum)<\/td> \u2265 2 TB SSD recommended; varies by setup<\/td> ~2 TB flat, up to ~6.5 TB with trie (Geth)<\/td> Minimal; no full chain stored<\/td><\/tr> Initial sync<\/td> Hours to days (sync-mode dependent)<\/td> Up to ~2 weeks (Geth path-based)<\/td> Seconds (Helios, reported)<\/td><\/tr> Typical use<\/td> Wallets, dApp backends, validation<\/td> Explorers, analytics, deep history<\/td> Mobile and lightweight apps<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n How to Choose the Right Type<\/h2>\n\n\n
Run Your Own or Use a Provider<\/h2>\n\n\n
\n