In Christian Lundkvists blog post about possible uses for IPFS, he suggests that storing the Ethereum blockchain as an IPFS object could potentially decrease the size of the chain:

We see the deduplication we gain when putting the state database on IPFS - between two blocks only the state entries that have been changed need to be explicitly stored.

What would be needed to implement this in practice? I can imagine that converting each block into an IPFS object manually could already be done if you want to save some space when importing/exporting a chain between trusted parties, but what about making this the standard way in which the blockchain is stored and distributed among the nodes?

  • 1
    This is great question.. – Jikku Jose Feb 2 '16 at 5:04

Note that putting the blockchain (and state etc) on swarm is already planned and thought out.

Integration with IPFS is also in the plan but may have some difficulties. If and when solved this answers your question.

Purely IPFS solution, full nodes can simply add their chaindata subdirectory to IPFS, while light clients download by hash, see this reddit post.

Both solutions need to find a way to reach consensus on the current canonical head block('s hash) which is not trivial.

Also both solutions benefit from an incentive scheme which ensures long term redundant storage.

EDIT: actually as Christian Lundkvist points out, this may not answer the question since "The question asks if we can encode the blockchain data structure into the IPFS Merkle DAG using IPFS objects, so that it is completely linked by IPFS hashes"

The answer to that is that it is easy with swarm manifest trie and a little unclear to me if it is just as easy in IPFS or not

  • Very cool, thank you for the links. So the easy part is separating the blockchain data structre into an IPFS object, but the hard part is to ensure that it is shared within everyone and essentially that people are seeding? – MrChico Feb 11 '16 at 16:47

Your Answer

