Exploring the Differences Between EVM Full Nodes and Archive Nodes

Introduction

Ethereum Virtual Machine (EVM)-based networks typically support two types of nodes: full nodes and archive nodes.

Popular EVM networks include:

• Ethereum
• Polygon
• BNB Smart Chain
• Avalanche C-Chain
• Fantom
• Harmony

Both full and archive nodes store complete blockchain data for replaying network states. The key difference is that archive nodes additionally preserve every historical network state in an accessible archive.

This article provides a detailed comparison of their functionalities, differences, and practical implementations.

Node Clients: Geth vs. Erigon

Geth (Go Ethereum)

• The most widely used EVM client
• Standard implementation for most EVM networks

Erigon (formerly Turbo-Geth)

• Focuses on efficiency and reduced resource consumption
• Second most popular EVM client

This guide focuses on Geth and Erigon implementations for both node types.

Full Nodes vs. Archive Nodes: Key Differences

Full Nodes

• Storage: Complete blockchain data

• Capabilities:

  • Validates all blocks and states
  • Can regenerate any state from stored data

• Limitations:

  • Prunes older state data (typically retains last 128 blocks)
  • Returns "missing trie node" errors for older state queries

Default accessible history:

Archive Nodes

• Storage: Everything in full nodes + complete historical state archive

• Advantages:

  • Instant access to any historical state
  • No state regeneration needed

• Disadvantages:

  • Significantly larger storage requirements
  • Longer initial sync time

Current storage sizes (approximate):

Practical Implementation

Deploying Nodes Quickly

Services like Chainstack's Bolt technology enable rapid node deployment:

1. Register an account
2. Deploy either node type in minutes

Querying Historical Data

These JSON-RPC methods support historical state queries when used with archive nodes:

1. eth_getBalance

Retrieves an address balance at a specific block.

Example (Web3.js):

web3.eth.getBalance('0x9D00f...', 14641000, (err, balance) => {
  console.log(web3.utils.fromWei(balance, 'ether'))
})

2. eth_getCode

Returns contract bytecode at deployment.

Example (cURL):

curl NODE_URL -X POST -H "Content-Type: application/json" --data '{"method":"eth_getCode","params":["0x1f984...","0xA5BC6A"],"jsonrpc":"2.0"}'

3. eth_getStorageAt

Reads contract storage at historical blocks.

Example (Web3.py):

storage = web3.eth.get_storage_at("0x954De...", 0, 7500943)
print(storage.decode("ASCII"))

FAQs

Q1: When do I need an archive node?

When your application requires:

• Historical state queries beyond 128 blocks
• Blockchain analytics tools
• Mainnet forks for testing
• The Graph protocol indexing

Q2: Can I convert a full node to an archive node?

No, they require different initial sync modes. You must deploy a new archive node.

Q3: What's the cost difference between node types?

Archive nodes typically cost 3-5x more due to storage requirements.

Conclusion

• Full nodes are sufficient for most DApps and recent data needs
• Archive nodes are essential for historical data analysis and development tools
• Services like 👉 Chainstack's node hosting simplify deployment

Choosing the right node type depends on your specific use case and data requirements. For most developers building standard DApps, full nodes provide the optimal balance of functionality and cost-efficiency.