The FOAM TCR aims to build a decentralized map of the world, which ultimately means we need to store our geospatial information in an immutable, verifiable manner. The most obvious approach is to simply store this data within some form of storage contract on that blockchain. While this approach has many drawbacks, such as contributing to the accelerating growth of the Ethereum state trie which would make us something of a bad neighbor; it also opens up the possibility of issues in the future storing and accessing this data. The concept of rent for on-chain storage has been discussed and may potentially be implemented at some point, which could mean that additional costs that are currently difficult to reliably account for (as they’re still fairly theoretical at this point) may come into play. If and when sharding comes along, it may become prohibitively expensive for end users to store useful quantities of data (for our application) on the Mainnet that we plan on deploying to (in addition to Mainnet rent to incentivize deploying applications on shards).

Finally, there are still issues in the present that affect the viability of storing such data on the chain itself, the primary one being that the Cartographers will end up paying gas costs to store Point of Interest data, which may end up being challenged or overwritten in the future with someone else paying a similar cost — leading to “wasted gas”. As a consequence, you’d have both the FOAM Token and the ETH paid for the gas to transact against the TCR (which would include the cost of the data storage) as a factor to consider in the economic stake behind a PoI. This throws a significant metaphorical wrench in the economic machinery behind a TCR and complicates the design process — and increasing complication is generally a good indicator that a different approach should be considered.

It should now be readily apparent that most of the signs point to on-chain storage of PoI data to be a Bad Idea™. Instead, we have the good fortune to be part of an ecosystem with insanely talented people working on some incredibly forward-thinking projects such as IPFS. IPFS is a content-addressed, peer-to-peer file sharing system — meaning that it has good decentralization properties due to its P2P nature, and because the unique identifier of a datum stored in the system is derived from the hash of its contents and metadata such as creation time, it’s possible to assert that the correct data is received when pulled from a peer. These hashes are fairly compact and consistently sized, so regardless of how rich and detailed the PoI data is, the on-chain storage burden remains constant. If there’s interest, we can delve into how we use IPFS and challenges faced for storing PoI data in a future blog post.

While we’ve presented a great theoretical case for why to avoid on-chain storage which should be enough to kill that approach and explore other avenues, no good theory is complete without some concrete numbers to act as nails in the coffin. To this end, we used all the components of our Web3 stack to rapidly iterate on some visualizations of how gas costs scale with the size of the data being stored on the chain. Thanks to our tooling, we were able to simply empirically test the gas usage of transactions storing data on chain in four different manners by running actual transactions against a real Ethereum blockchain.