In the series of articles I’ve been writing since the beginning of the year, we have always focused on where a blockchain is headed: the block production mechanisms, consensus, peer-to-peer latency, etc. However, for this article, I want to go back to something much simpler and rather old: the first blocks of a blockchain.
Like everything else, a blockchain has a beginning: a first block, or a genesis block, so to say. Then another block gets added to it, and another. In time transactions modify balances, contracts change their states, and the network gradually builds a history of everything that has happened since its beginning. At first, keeping this history is not much of a concern because there is simply not that much to keep.
The situation becomes different after years of operation as the blockchain may have produced millions of blocks and processed billions of transactions, while every new block continues adding more information to what was already there. We usually consider this history permanent because once a block becomes part of the canonical chain, changing what happened becomes increasingly difficult.
Bitcoin is a good example of how physical this problem eventually becomes. Today, synchronizing Bitcoin Core requires downloading more than 740 GB of blockchain data. Ethereum is more complicated because of its changing state: depending on the client and the type of historical state being retained, an archive node can require multiple terabytes of storage, with some implementations requiring considerably more than others.
However, the machines storing this history do not grow together with the blockchain. Storage is limited and expensive, while the chain is expected to continue growing indefinitely. At some point, node operators therefore have to make a decision: how much of the past do they actually need to keep in order to follow the present?
Leaving the Earlier Blocks Behind
A node synchronized with the tip of a blockchain does not necessarily need every previous version of its state to continue running. What matters for most of its daily operation is the current state and the information required to verify the blocks that come next. And at this point, node operators make use of something called pruning. Instead of keeping all historical information indefinitely, a node can remove data that is no longer required for its operation of adding new blocks to the blockchain. Depending on the blockchain and the way the node is configured, this can significantly reduce storage requirements without preventing it from remaining synchronized with the network.
How aggressively this can be done also depends on the architecture of the blockchain. Bitcoin Core, for example, can reduce its storage requirement from hundreds of gigabytes to only a few gigabytes in pruning mode while still validating the blockchain. In Cosmos SDK chains, operators can go even further with historical state: the software can be configured to retain only two-to-three blocks.
Nevertheless pruning does not make the current consensus less secure. A properly configured pruned node does not become a weaker participant simply because it cannot answer a query about the state from several years ago. It can still verify the information required by the protocol and follow the current chain with the same consensus rules.
All in all, from the perspective of a node operator, the decision is understandable. The blockchain grows continuously but hardware does not and keeping information that is rarely queried comes with a real and high cost. The node therefore follows the chain towards its tip and gradually leaves some of the earlier state behind.
But this creates another question: what happens when we want to go back?
What Happened Five Years Ago?
Suppose we want to understand exactly what the blockchain looked like at a particular block five years ago. This is not necessarily an unusual request. Financial records may remain legally relevant for years, an old transaction may become part of a court case, or an application may need to prove what a particular account or contract looked like at the time an agreement was executed. In such cases, knowing the current state is simply not enough. We may need to inspect an account balance, the value of a contract, or some other part of the state exactly as it existed when that block was produced.
Thousands of nodes might have received and verified that block at the time. Yet, years later, many of those same nodes may no longer be able to answer our question. They can be perfectly healthy, synchronized with the latest block and independently verifying the network while no longer keeping the historical state we are looking for.
Here, we need to distinguish between a few concepts that are usually put together when we describe blockchains as permanent: immutability, availability, and verifiability.
Blocks and states are connected through cryptographic commitments. Merkle-based structures, for example, allow enormous amounts of blockchain state to be represented by a relatively small root commitment. This means that even if we do not store the historical state ourselves, someone who preserved it can later provide us with a particular piece of information together with the necessary proof. We can then check that proof against the commitment preserved by the blockchain and verify whether the information really belonged to that historical state. In other words, we may depend on someone else to provide the old data, but we do not necessarily have to trust them about what that data contains.
However, a commitment to information and the information itself are different things. Let’s say if I give you a file together with its hash: you can verify whether the file is the one I originally committed to. If every copy of the file disappears and only its hash remains, however, the hash cannot recreate the file.
This distinction applies to blockchain history too. Cryptography can allow us to verify historical information once we obtain it, but cryptography cannot make unavailable information available.
In other words, immutability does not automatically imply availability.
Who Keeps the Past?
Of course, historical blockchain data does not normally disappear simply because ordinary nodes prune it. There are archive nodes specifically maintained to preserve historical state, while indexers, explorers and RPC providers make different parts of that history accessible to applications and users.
But this changes the decentralization problem in an interesting way. There may be thousands of nodes capable of independently verifying what happens on a blockchain today, while only a much smaller number of machines can answer what an account looked like five years ago. Those archive operators cannot simply invent another historical state and convince us that it is legitimate thanks to the cryptographic commitments.
They can, however, choose not to provide it at all.
This means that historical integrity and historical availability have different security models. Consensus and cryptography protect us against someone changing the past, while access to that past still depends on someone continuing to store and serve it. In that sense, the older parts of a blockchain can gradually become more centralized in their availability even though they do not become more centralized in their truth.
This is not necessarily a problem. Requiring every node to preserve every historical state forever would mean that the hardware requirement for participating in a blockchain would continuously increase simply because the network survived another year. After decades, operating an ordinary node could require storing an enormous amount of information that has almost no relevance to current consensus. Therefore, for a blockchain expected to operate indefinitely, some form of forgetting is almost unavoidable.
Conclusion
We often treat permanence as if it were one property of a blockchain, but it is actually the result of several different guarantees. A blockchain can make its history extremely difficult to modify without requiring every participant to preserve every historical state forever.
If every node were required to carry everything the network had ever known, the cost of participating would increase indefinitely with the age of the blockchain. Pruning prevents this by allowing the majority of nodes to concentrate on verifying the present while a smaller part of the infrastructure preserves the past.
This creates a trade-off that is easy to overlook. As history gets larger, its integrity can remain protected by the blockchain while its availability becomes dependent on fewer participants. And those participants cannot easily lie about what happened but they may eventually become the only ones left who can show us.
Then, the question becomes not whether a blockchain can preserve its history forever, but who will still be there to provide it when we want to look back?