Question 1

Full node vs archive node

Accepted Answer

TL;DR: A full node stores the current state of the blockchain and validates all new transactions and blocks, but prunes older historical data to save storage. An archive node does everything a full node does, plus it retains the complete historical state of the chain from the genesis block forward. The type you need depends on whether your application requires current data or access to any historical state at any point in time. The Simple Explanation Every blockchain node downloads and verifies the chain, but not every node keeps the same amount of data around. Think of it like a library versus an archive. A full node is the library: it has every book currently in circulation and can tell you what is on the shelves right now. An archive node is the national archive: it has every book that was ever published, every edition, and every out-of-print manuscript going back to day one. On Ethereum, a full node stores the current state of all accounts, balances, and smart contracts, along with enough recent block history to verify the chain's integrity. By default, most Ethereum clients keep the last 128 blocks of state data readily accessible, which covers roughly the last 25 to 30 minutes of network activity. Anything older than that gets pruned to save disk space. The full node can still technically reconstruct older states by replaying transactions from the genesis block, but that process is extremely slow and computationally expensive. An archive node skips the pruning entirely. It stores a snapshot of the entire blockchain state at every single block since the chain's inception. This means you can query the balance of any wallet, the storage of any smart contract, or the output of any transaction at any point in the chain's history, and get an instant response. No replaying required. The tradeoff is storage. A full Ethereum node running Geth needs around 1TB of SSD space. An archive node running Geth needs over 12TB, and that number grows every day. Erigon, a more storage-efficient client, brings archive requirements down to roughly 2TB, but it is still significantly more than a pruned full node. What is the difference between a full node and an archive node? Both node types validate the chain and store the current state, but only an archive node keeps every historical state snapshot. The table below summarizes the practical differences. If you are still deciding which node type to operate, our overviews of what a blockchain node is and running a node versus using an RPC provider add helpful context. AttributeFull nodeArchive nodeHistorical statePruned after ~128 blocksRetained from genesisStorage (Ethereum, Geth)About 1TBOver 12TB (about 2TB on Erigon)Historical state queriesReturn a missing trie node errorInstant at any block heightSync timeHours to daysDays to weeksBest forWallets, dapps, payments, real-time readsExplorers, analytics, audits, tracing When You Need a Full Node Full nodes are the workhorses of any blockchain network. They validate every new block, enforce consensus rules, reject invalid transactions, and serve as trust anchors for lightweight clients that do not store the full chain. If you are building a wallet, a dapp that only needs current balances and recent transaction data, or a service that submits transactions to the network, a full node is sufficient. Most production applications fall into this category. A decentralized exchange needs to know current token balances and execute swaps in real time. A payment processor needs to verify that incoming transactions are valid and confirmed. A wallet needs to display current balances and broadcast new transactions. None of these use cases require querying what a specific account's balance was 500,000 blocks ago. Current state is enough, and a full node delivers it with dramatically lower hardware requirements than an archive node. Full nodes also play a critical role in network health. The more independent full nodes running on a blockchain, the more decentralized and resilient the network becomes. Each full node independently verifies the chain, so no single node or group of nodes can unilaterally alter the record. Running a full node is the most direct way to participate in and support a blockchain's security model. When You Need an Archive Node Archive nodes become essential when your application depends on historical blockchain data. If you are building a block explorer that lets users look up any transaction or account state from any point in the chain's history, you need archive access. If you are running analytics that track how token holdings, smart contract states, or DeFi protocol metrics have changed over time, you need archive access. If you are forking mainnet using development tools like Hardhat or Foundry to simulate past conditions for testing, you need archive access. Specific technical scenarios also demand archive nodes. Calling eth_getBalance or eth_call at a historical block number (anything older than the last 128 blocks on most clients) requires archive data. Debugging a failed transaction from weeks ago by tracing its execution requires archive data. Reconstructing the state of a lending protocol at a specific block to audit a liquidation event requires archive data. Without an archive node, these queries will return a "missing trie node" error because the data has been pruned. The audience for archive nodes is narrower but critical: blockchain analytics platforms, forensic investigators, protocol auditors, indexing services like The Graph, and any application that needs to answer questions about the past, not just the present. Why do historical queries fail on a full node? A full node prunes state older than roughly the last 128 blocks, so calling eth_getBalance or eth_call at an older block returns a missing trie node error. The transaction record still exists, but the state at that moment was deleted to save space. Recovering it requires an archive node or a stored dataset, which is the core idea behind accessing historical blockchain data. This pruning is also why querying blockchain data at scale often needs more than a single full node. How much storage does each node type need? Storage is the biggest practical difference, and it depends on the chain and client. The table shows typical Ethereum figures. These numbers grow continuously, which is one reason many teams query historical state through a provider instead, as covered in real-time vs historical blockchain data. ConfigurationApproximate storageNotesFull node (Geth)About 1TBPrunes old stateArchive node (Geth)Over 12TBStores every state snapshotArchive node (Erigon)Roughly 2TBMore storage-efficient client The Storage and Cost Reality Running your own archive node is a serious commitment. Beyond the 12TB+ storage requirement for Ethereum alone, you need high-performance SSDs (not HDDs) for acceptable query speed, and syncing an archive node from scratch can take weeks depending on your hardware and internet connection. If your node falls out of sync or crashes during the initial sync, you may need to start over. Multiply that by every chain your application supports, and the infrastructure burden scales quickly. This is why most developers and teams rely on infrastructure providers rather than running archive nodes themselves. Quicknode includes archive data access across all plans, meaning you can query any historical state on any supported chain without managing the underlying storage or sync process. Whether you need the last 10 minutes of data or the full history back to genesis, Quicknode's Core API handles it through the same RPC endpoint. For teams that need dedicated, isolated infrastructure, Quicknode's Dedicated Clusters provide private archive node access with guaranteed uptime SLAs and predictable performance. Can one endpoint serve both full and archive data? Yes. Many providers route current-state requests to full nodes and historical-state requests to archive nodes behind a single URL, so you do not have to manage two setups. From the application side it is just one RPC endpoint that answers both recent and historical queries. Further Reading Ethereum Full Node vs. Archive Node - Quicknode Guide How to Install and Run a Geth Node - Quicknode Guide Quicknode Core API Dedicated Clusters - Quicknode Frequently Asked Questions Is an archive node the same as a full node? No. An archive node does everything a full node does and also keeps every historical state snapshot from genesis. A full node prunes old state to save disk space, so it cannot answer arbitrary historical state queries. Do I need an archive node for my dapp? Most dapps, wallets, and payment apps only need current state, so a full node is enough. You need archive access mainly for block explorers, analytics, audits, mainnet forking, and tracing historical transactions. Why does eth_getBalance fail at an old block? Because a full node has pruned the state for that block, the call returns a missing trie node error. Querying an archive node, which retains every state snapshot, resolves it. How much does an Ethereum archive node store? Around 12TB or more on Geth, compared to about 1TB for a full node. The storage-efficient Erigon client reduces archive storage to roughly 2TB, and all of these figures grow over time. How do archive nodes relate to indexing? Indexers often read historical data from archive nodes or backfilled datasets to build queryable databases. For how that layer works, see what blockchain indexing is.

Question 2

What does it mean to run a node?

Accepted Answer

Running a node means operating a computer that participates in a blockchain network by downloading, validating, and relaying transactions and blocks. It gives you direct, trustless access to blockchain data without relying on any third party. While running your own node offers maximum sovereignty and privacy, it comes with real costs in hardware, maintenance, and operational complexity that most developers and teams choose to offload to infrastructure providers.

Question 3

What is a blockchain node?

Accepted Answer

A blockchain node is a computer running software that maintains a copy of the blockchain, verifies transactions, and relays data across the network. Nodes are the backbone of every blockchain. Without them, there is no network. Different types of nodes serve different purposes, from lightweight nodes that verify transactions to full archive nodes that store the entire history of the chain.

Question 4

Why node reliability matters

Accepted Answer

Node reliability is the measure of how consistently and accurately a blockchain node responds to requests without downtime, errors, or stale data. For any application that reads from or writes to a blockchain, unreliable node infrastructure means failed transactions, incorrect balances, missed events, and broken user experiences. In production environments, node reliability is not a nice-to-have. It is the foundation everything else depends on.

속성	풀 노드	아카이브 노드
역사적 상태	약 128블록 후에 정리됨	창세기에부터 이어져 온
저장소 (Ethereum, Geth)	약 1TB	12TB 이상 (Erigon 기준 약 2TB)
과거 상태 조회	누락된 트라이 노드 오류 반환	어떤 블록 높이에서든 즉시
동기화 시간	시간에서 일까지	며칠에서 몇 주
다음에 가장 적합합니다	지갑, DApp, 결제, 실시간 조회	탐색, 분석, 감사, 추적

구성	대략적인 저장 용량	참고 사항
풀 노드 (Geth)	약 1TB	프룬의 이전 상태
아카이브 노드 (Geth)	12TB 이상	모든 상태 스냅샷을 저장합니다
아카이브 노드 (Erigon)	대략 2TB	저장 공간 활용도가 더 높은 클라이언트

최신 소식을 받아보시겠습니까?

개발자 도구

문서 및 가이드

풀 노드 대 아카이브 노드

간단한 설명

풀 노드가 필요한 경우

아카이브 노드가 필요한 경우

풀 노드에서 역사 조회 쿼리가 실패하는 이유는 무엇인가요?

각 노드 유형마다 얼마나 많은 저장 공간이 필요한가요?

저장 공간과 비용의 현실

하나의 endpoint 서버로 전체 데이터와 아카이브 데이터를 모두 제공할 수 있습니까?

추가 자료

자주 묻는 질문

아카이브 노드는 풀 노드와 같은 것인가요?

제 DApp에 아카이브 노드가 필요한가요?

왜 eth_getBalance는 오래된 블록에서 실패할까요?

Ethereum 아카이브 노드에는 얼마나 많은 데이터를 저장할 수 있나요?

아카이브 노드는 인덱싱과 어떤 관련이 있나요?

지금 바로 시작하세요