Archive Nodes: The Pinnacle of Node Setups

Running an archive node for a blockchain like Ethereum or Polygon is an undertaking that’s both labor-intensive and costly. It’s more or less the pinnacle of node setups. The node will require good hardware, maintenance (i.e., good monitoring), and also time—at least whenever monitoring kicks in or a new release is due. Typically, one will only take this on for a specific reason.

An archive node is more than a full node. A full node “only” stores the entire blockchain, whereas an archive node additionally stores every state that each smart contract and transaction ever had (i.e., at every block height). However, the additional data of an archive node can be reconstructed from the data of a full node.

Since this often leads to discussions on Twitter or online forums, I like to bring an analogy to Bitcoin: An archive node for Ethereum is akin to a Bitcoin node that stores the UTXO (Unspent Transaction Output) set valid at every block height. This isn’t particularly interesting for Bitcoin because (a) these data can be reconstructed much faster and (b) they don’t hold any special informational value. It’s different with Ethereum because there are smart contracts whose intermediate states are stored, making it possible to directly query, for example, how much USDT an account had at any given time (block height).

I synchronized my first archive node for the Ethereum ecosystem in 2019. It was out of pure curiosity: I had purchased a lot of server hardware for a project (96 cores, 768 GiB RAM, over 40 TiB SSD storage) and wanted to push it to the limit. So, I synchronized an archive node for Ethereum using geth, which took exactly 7 days and 22 hours. I still remember it so precisely because I discussed the topic on coinforum.de and documented my progress.

Long-term, better reasons are needed. That’s a significant difference between Ethereum and Bitcoin. Bitcoiners synchronize the entire blockchain out of idealism. In Ethereum, most users utilize node providers like Infura or Alchemy. These providers allow roughly 100,000 free API calls, sufficient for smaller projects and wallets.

When and for whom is an archive node useful?

It becomes critical when one wants or needs to conduct blockchain analyses. If, for instance, you want to know which accounts held what amounts of a token on Ethereum at any time, you need to scan the blockchain block by block to find all addresses and then query the historical balances for each ERC20 transaction. This quickly exceeds the free API calls provided by Alchemy and Infura and can become expensive fast. In such cases, an archive node is worthwhile because scanning all blocks leads to as many API calls as there are blocks in the blockchain. Ethereum currently has over 20 million blocks.

I now operate such nodes for clients. The reasons can sometimes be absurd. For instance, a company offers assistance in complying with EU regulations, which require demonstrating the CO2 consumption for each crypto asset. If you have a token on Ethereum, you must trace back all past transactions and swaps to calculate the gas used by the token. The gas corresponds to the required computational power and thus serves as an indicator of CO2 consumption.

This is, of course, ludicrous. As a Proof-of-Stake blockchain, Ethereum consumes very little energy, and synchronizing an archive node likely generates far more CO2 than you could ever save through the regulation (if at all). But it’s not my job to ask such questions, but rather to set up nodes.

What resources are needed to operate an Ethereum archive node?

The differences between nodes and clients can be substantial. I have experience with Ethereum, Polygon, and Solana.

Using the Nethermind client, Ethereum requires about 15 terabytes of storage for the execution layer data, 8 CPU cores (preferably 16 for synchronization), and 128 gigabytes of RAM. An alternative client is Erigon, which requires only three terabytes of data. Erigon stores data differently than Nethermind, using a flat architecture that only saves deltas between some blocks. This may result in slightly longer query times for historical data but saves a lot of space.

For a server, the demand is moderate. Once synchronized, less is needed. The biggest challenge is the hard drives, or rather the SSDs. To understand why, you must know how smart contracts work with the Ethereum Virtual Machine (EVM). I’ll keep it brief: Each smart contract has its own virtual memory space, which may load different parts depending on the account. This leads to numerous read and write operations (I/O) with each new block and during synchronization.

Therefore, traditional hard drives (HDDs) are outdated; SSDs are needed. Users of Nethermind must chain several SSDs together to store at least 15 terabytes. This can quickly cost a four-figure amount if