Critics of Ethereum are concerned that the Ethereum blockchain is too big. They are concerned that it takes up too much storage space.
Storage space is an issue because, if the everyday user is unable fit the blockchain on their laptop, they will be unable to locally validate the blockchain.
If the average user is unable to run a full node, they will lose the ability to experience the full potential of crypto. This may also give third parties who are able to run full nodes more influence on how the Ethereum blockchain evolves in the future.
In this post, I am going to dispel the myth that the everyday users cannot run a fully verified Ethereum node because of storage requirements. I am going to describe how a pruned Ethereum node can be fully verified.
What do we mean by full node?
If you run a full node, it means that your Ethereum client constructed and validated the current state of your local blockchain (i.e. blockchain on your laptop) since the genesis block and can serve a full copy of the blockchain to other nodes.
How does a full node verify the current state of the blockchain?
A full node downloads every single Ethereum block that ever existed from its peers (other Ethereum nodes) but also checks that these blocks are not “fake blocks.” Your node will verify that these blocks are legitimate by replaying all transactions since the genesis block (aka the first block), by checking that these blocks followed all of the consensus rules and by making sure that all transactions are valid.
Once your local blockchain validates the latest block in the network, it is synced and now officially a full node.
The key takeaway from this local validation process is that, although you receive every block since genesis from your peers in the Ethereum network, you did not need to blindly accept any data from your peers to arrive at the latest state of the blockchain. You arrived at the current state of the Ethereum blockchain through a “trustless” process.
Does a full node need to be an archival node?
People think that in order to have a fully verified Ethereum blockchain (aka full node), you need to run an archival Ethereum node. Running an archival node is thought to be an issue for Ethereum because an archival node currently takes up to 1.4 Terabytes (data point provided by Afri Scheoden, a developer at Parity Tech).
An archival node saves all of the intermediary/transitional/historical states of each block. Each time a block is added, state data is added and removed from latest version of the state trie. Although data is continuously added and removed from the latest version of the Ethereum state, an archival node keeps all of the pruned data relevant to previous states anyway.
Archival nodes can use this data to view the state of Ethereum at each historical block. This means you can see what every public key balance and smart contract state looked like at any specific point (or more accurately “block”) in time. Are you curious about what all accounts looked like on block 4199900? An archival node will have the entire global state saved at that time.
As you can see, an archival node is more than a full node and not necessarily required. My main argument in this post is that we do not need to run an archival node to run a fully verified blockchain. We can run a full node with a pruned state trie as well!
A pruned node that fully verifies the blockchain?
The Parity Ethereum client gives you the option to fully verify and replay every transaction/block since genesis, but also allows you to prune the Ethereum state tries in order to save space. This means that after 1024 blocks, all data pertaining to historical Ethereum states is deleted.
Pruning the state trie saves tons of disk space because it is the historical state data that is creating the blockchain bloat. A pruned blockchain can take up 90 GB compared to the 1.4 Terabytes taken up by an archival node (data point provided by Afri Scheoden, a developer at Parity Tech).
Although data from older state tries are deleted, all of the information necessary to recreate that state trie is still saved on your local blockchain. In order to construct a full Ethereum node that is also pruned, use the — pruning fast (on by default) and the — no-warp option using the Parity Ethereum client.
Pruning is still a trade off!
The reason that pruned blockchains still save more historical states than just the latest block is because it needs these states in case there is a reorganization of the blockchain. A reorganization of the blockchain happens when a version of the blockchain with a higher cumulative difficulty appears and reverts several of blocks in the blockchain.
The default number of historical states saved for a pruned blockchain on Parity Ethereum is 1024 but you also have the option to increase this number if you would like to further protect yourself from chain reorganizations.
Can the everyday user still run a full node though???
Hopefully, I convinced you that the Ethereum storage requirements is not a barrier to entry for the everyday Ethereum user.
In future posts, I may explore other issues preventing users from experiencing the full benefits of running a node. I am particularly interested in comparing the user experience of running a full node in comparison to just using Etherscan.
Thanks for reading!
I would like to give a special thanks to Afri Scheoden for proof reading my article. Thank you Afri for taking the time out of your busy schedule.