The Ethereum-blockchain size will not exceed 1TB anytime soon.
Tags: ethereum, parity, blockchain, bitcoin
Published: 2017-11-29 11:08:11

---
title: "The Ethereum-blockchain size will not exceed 1TB anytime soon."
published: true
description: "Once a month users post a chart on `r/ethereum` predicting the blockchain size of Ethereum will soon exceed 1 TB. I want to clean up with some stories around the Ethereum-blockchain size in this article and try to explain why this chart is technically correct, but not the full picture..."
cover_image: https://i.stack.imgur.com/5wDYH.png
tags: ethereum, parity, blockchain, bitcoin
---

_Before diving into this article, please read the two disclosures about my involvement (1,2) and the one on data accuracy (3) at the bottom of the article._

At least once a month someone posts a [chart](http://bc.daniel.net.nz/) on [r/ethereum](https://reddit.com/r/ethereum) predicting the blockchain size of Ethereum will soon exceed 1 TB. I want to take that chance to clean up with some stories around the Ethereum-blockchain size in this article and try to explain why this chart is technically correct, but not the full picture.

![Some chart](https://i.imgur.com/A5tl3oY.png)

Let's have a look at this chart first. It shows the complete data directory size of an Ethereum node (red), [Geth](https://github.com/ethereum/go-ethereum/) in this case, and a Bitcoin node (blue), probably [Bitcoin-Core](https://github.com/bitcoin/bitcoin), plotted over time. While the Bitcoin graph is moving slightly upwards in a seemingly linear inclination, the Ethereum graph reminds the reader of an exponential growing slope.

### On Blocks, Block-History, States, and State-History

Users accusing Ethereum of _blockchain-bloat_ are not far off with their assumptions. But actually, not the chain is bloated but the Ethereum _state_. I want to examine some terminology from the [Whitepaper](https://github.com/ethereum/wiki/wiki/White-Paper) before proceeding. 

- **Block**. A bundle of transactions which, after proper execution, update the state. Each transaction-bundling block gets a number, has some difficulty, and contains the most recent state. 
- **State**. The state is made up of all initialized Ethereum accounts. At the time of writing, there are around 12 million known accounts and contracts growing at a rate of [roughly 100k new accounts per day](https://etherscan.io/chart/address).
- **Block-History**. A chain of all historical blocks, starting at the _genesis_ block up to the latest best block, also known as the _blockchain_.
- **State-History**. The state of each historical block makes up the state history. I will get into the details on this later.

If this already bores you, now please, read on.

### Understanding Pruning-Modes and Sync-Modes

Early 2016, the Go-Ethereum team introduced a so-called _[fast](https://ethereum.stackexchange.com/q/1161/87)_ synchronization mode. Since then, it was pretty famous to run `geth --fast`, especially after the [spam-attacks](https://blog.ethereum.org/2016/09/22/transaction-spam-attack-next-steps/) on Ethereum later the same year making a _full_ synchronization mode painful. I'm writing these modes _italic_ because I will come back to an essential disambiguation at a later point in this article. Just keep them in mind for now.

The Parity team (formerly Ethcore) reacted to the on-chain spam by offering a _[warp](https://ethereum.stackexchange.com/q/9991/87)_ synchronization mode at the end of 2016 to ease the chain synchronization for new users. Much as the same as Geth's _fast_, `parity --warp` soon became the de-facto standard mode for users trying to synchronize the Ethereum chain. As of today, both these options are adapted as default in both clients.

But **what does it mean to _fast_-sync** versus _full_-sync a Geth node? **What does it actually mean to _warp_-sync** a Parity node rather than _no-warp_-syncing it?

A _full_ Geth node processes the entire blockchain and replays all transactions that ever happened. A _fast_ Geth node downloads all transaction receipts in parallel to all blocks, and the most recent state database. It switches to a _full_ synchronization mode once done with that. Note, that this results not only in a _fast_ sync but also in a _pruned_ state-database because the historical states are not available for blocks smaller than best block minus 1024. That's not an issue, but before reading on, please keep in mind that Geth synchronization modes are also pruning modes. 

Looking at Parity configuration options, this gets more complex. In addition to the previously mentioned synchronization modes, Parity also offers separate _pruning_ modes, namely _fast_ and _archive_... Right, Geth _fast_ is a sync-mode, we learned, that even prunes, however, Parity _fast_ is pruning mode not heavily coupled to the sync mode. At this point, I have to admit, the terminology is confusing, and I might have lost you already. Let's draw something with pen and paper.

![Pen and paper.](https://i.imgur.com/xRfwjsM.png)

Geth's _fast_ enables a quicker synchronization and database pruning. Geth _full_ disables both. **Parity _warp_, however, can be disabled without disabling the state-trie pruning!** This is a significant sentence. Thus I **bolded** it. And I am not comparing Ethereum clients here, that's not my intention at least. **I want to show you that it is possible to run a full-verifying Ethereum node with a small database.** Parity just provides the proof-of-concept for this.

But why is this? Because as long as you have all historic blocks on your disk, you can compute any historical state from it by reprocessing the entire chain again. But in most use-cases, you don't need historical states at all! Therefore it is smart just to delete outdated entries from the state history and to reduce your required disk space by 95%.

### So, what's the minimum Size of a full-verified Node?

Some 10's of GB by just running `parity --no-warp`. Earlier this fall it was less than **20 GB**, but the state is growing very fast. Currently, the raw historical block data containing the blocks and transactions is approximately 12-15GB in size and the latest state around 1-2GB. 

But **is this to be considered a _full_ Ethereum node**? Yes:

- It runs a full blockchain synchronization starting at _genesis_.
- It replays all transactions and executes all contracts.
- It recomputes the state for each block.
- It keeps all historical blocks on the disk.
- It keeps the most recent states on the disk and prunes ancient states.

Something an Ethereum client never does is deleting old blocks. This is a significant difference between Bitcoin and Ethereum because _pruning_ a Bitcoin node does not leave any choice but [removing old blocks](https://bitcoin.stackexchange.com/a/37497/6441). With this context available, it's easier to understand why users often think a pruned Ethereum node is not a full node. But now, dear reader, you know the opposite is `true`. :)

And on top of this, even a _warp_-synced Parity node is downloading the whole history of blocks after the initial synchronization allowing it to serve the network as a _full_ node once completed the ancient-block synchronization.

### The Full Picture: 9 Parity Configurations compared

Below is a screenshot of my nicely-colored spreadsheet trying to distinguish between node-security of different Parity operation modes.

![The full picture.](https://i.stack.imgur.com/2cPjk.png)

The configurations `00` through `05` are all to be considered _full_ nodes. Configuration `06` is a default-configuration _warp_-node which can be regarded as _full_ once the ancient block download is finished. However, it does not replay all transactions; it only checks the Proof-of-Work of the historical blocks.

---

The configuration `07` is something [users often ask for](https://ethereum.stackexchange.com/a/31848/87) but should be highly discouraged in production use. This setting is comparable to a pruned bitcoin node as historical blocks are partially not available. This is _not_ a full node anymore. Note, how I added a separator above this paragraph. You get the idea.

Configuration `08` is a light client, but that's worth another blog article. Thanks for scrolling this far down, here is your conclusion: An Ethereum full node does not require more than 20-30 GB disk space by default. :)

---

_Noteworthy disclosures and bottom-line comments._

_(1) I work for Parity. I'm comparing different Parity configurations not only because I sincerely know and understand them, but also because Parity allows users to configure pruning mode and synchronization mode separately._

_(2) I hold some Bitcoin and some Ether. I hope this does not have any influence on the technical aspects I'm outlining in this article. Also, I'm trying not to become overly political about this._

_(2) I have been running Parity in 36 different configurations over six weeks to gather the numbers. This is time- and resource-consuming, and still, it bears the issue that I can not keep all configurations running at the same time, and therefore, the accuracy of the numbers presented in this article have to be consumed with caution. I expect the results to differ up to plus/minus 20% from other nodes running the same configuration. But you [get the idea](https://ethereum.stackexchange.com/a/31195):_


    | ID | Pruning / DB Config | Verification    | Available History          | ETH        | ETC        | MSC        | EXP        | Parity CLI Options                         |
    |====|=====================|=================|============================|============|============|============|============|============================================|
    | 00 | archive +Fat +Trace | Full/No-Warp    | All Blocks + States        | 385     GB |  90     GB |  25     GB |   5.6   GB | --pruning archive --tracing on --fat-db on |
    | 01 | archive +Trace      | Full/No-Warp    | All Blocks + States        | 334     GB |  90     GB |  21     GB |   5.8   GB | --pruning archive --tracing on             |
    | 02 | archive             | Full/No-Warp    | All Blocks + States        | 326     GB |  91     GB |  30     GB |   5.5   GB | --pruning archive                          |
    | 03 | fast +Fat +Trace    | Full/No-Warp    | All Blocks + Recent States |  37     GB |  13     GB |   3.5   GB |   1.3   GB | --tracing on --fat-db on                   |
    | 04 | fast +Trace         | Full/No-Warp    | All Blocks + Recent States |  34     GB |  13     GB |   3.5   GB |   1.2   GB | --tracing on                               |
    | 05 | fast                | Full/No-Warp    | All Blocks + Recent States |  26     GB |   9.7   GB |   3.0   GB |   1.1   GB | --no-warp                                  |
    | 06 | fast +Warp          | PoW-Only/Warp   | All Blocks + Recent States |  25     GB |   9.6   GB |   2.6   GB |   0.96  GB |                                            |
    | 07 | fast +Warp -Ancient | No-Ancient/Warp | Recent Blocks + States     |   5.3   GB |   2.9   GB |   0.19  GB |   0.13  GB | --no-ancient-blocks                        |
    | 08 | light               | Headers/Light   | No Blocks + No State       |       5 MB |       3 MB |       4 MB |       5 MB | --light                                    |

_Meta-data:_

    Version: Parity/v1.8.0-unstable-7940bf6ec-20170921/x86_64-linux-gnu/rustc1.19.0 from source w/ musicoin support
    Ubuntu: 17.04 Kernel 4.10.0-35-generic / September 2017 / Lenovo Thinkpad X270, Core i7-7600U, 1TB SSD, 16GB RAM

_Thanks for scrolling to the bottom._ <3

---

_Update_: Thanks for featuring me on [dev.to](https://dev.to/) and [twitter](https://twitter.com/ThePracticalDev/status/935967812987817984). Users who enjoyed reading this article, might also find the following [reddit discussion](https://www.reddit.com/r/ethereum/comments/7gcheo/the_ethereumblockchain_size_will_not_exceed_1tb/) interesting.

_Fun fact_: While publishing this article, the price of Bitcoin broke 10_000 USD and Ethereum 500 USD. I think I will add current market prices to my articles in future, just for fun.

---

_Update_: Thanks for rating this [top-1 post](https://dev.to/thepracticaldev/the-7-most-popular-dev-posts-from-the-past-week-egg-6e71), dear dev.to team <3 <3 <3

---

_Update_: Here is a more controversial discussion on [Hackernews](https://news.ycombinator.com/item?id=15935342).