As we’ve started talking about Scrypto and all of the smart contract features it will enable for developers, we’ve gotten some questions from our developer community about data storage. If a developer can write all of this great smart contract code with Scrypto and have it be scalable, will they also be able to store data on Radix that goes with that smart contract logic?

In general, right now we don’t see an urgent need to integrate on-ledger data storage into the Radix protocol and a lot of downside to doing it – and so we have no immediate plans on focusing on it. However we want to explain more about this, and why we don't think this limits what you can do with Radix at all.

DLT-based Data Storage is Hard

Bulk data storage on blockchains/DLTs is a hard and very specific problem - both in technical implementation and in how you build in the right economic incentives so that it can be decentralized. There are some other projects (like Filecoin and others) that are totally focused on optimizing a blockchain protocol for this usage. It's pretty unlikely that Radix (which is highly optimized for efficient transactions, assets, smart contract logic, etc.) is going to do a better job of it trying to mash those functions together.

Also, other solutions have yet to prove that the economics of blockchain-based storage actually work vs. non-decentralized solutions (like S3) or existing decentralized solutions (like IPFS). Scattering data around arbitrary sets of computers in a way that is usable and reliable ends up being really inefficient and that inefficiency has a very real cost that has to be justified by the benefits provided. Maybe Filecoin or somebody else will pull it off, but so far usage is very niche.

All of this is to point out that choosing to offer bulk data storage on Radix is a huge new development burden, an adder of complexity to the protocol, a potential spoiler for the performance of Radix, and probably not of much value – if there are other solutions that can integrate with Radix dApps and serve the needs of developers.

The Need for Storage Solutions for dApps

So compared with that tradeoff, let's talk about the benefits to developers of offering on-ledger storage of data to go with dApps. There are two main reasons why it might be valuable:

1. The developer wants to immutably link an on-ledger asset to some data (eg. a piece of jpeg art linked to an NFT)
2. The developer wants the data to be as decentralized as the associated smart contract logic and assets (eg. web frontend code for a dApp).

But is building data storage into Radix the only solution – or even best solution – to meet these needs?

#1 can be handled in much better ways. Any piece of data can be uniquely "hashed", creating a short string of characters that can be easily stored on the Radix ledger inside an NFT or other asset or component. This hash string provides an absolute immutable link between a piece of data off-ledger and its representation on-ledger that it must be uniquely connected to – without actually putting the data itself on the ledger. This in fact is the approach that virtually every NFT system takes today. This works great, as long as the associated data can be reliably stored and accessed somewhere by users. So that brings us to #2...

#2 is perfectly well answered by other purpose-built storage options. This might be Filecoin, IPFS, or something else. And many applications may find that decentralization actually isn’t necessary for their particular data when really all they need is many copies of the data on various traditional storage options to ensure availability. The decentralized options may even reduce flexibility if the on-ledger assets (the token or NFT itself) and logic (core dApp functionality to manage assets) are really the only part of the dApp that must be “unstoppable”.

Separate Data from Logic and Assets

How can off-ledger solutions offer the same benefit to developers?

On a smart contract platform like Radix (as it will be at Babylon), the primary reason to have anything directly on-ledger is because you need system logic or smart contract logic to be able to act based on that data. The smart contract needs to be able to see and read the data to create a different result in a transaction. For example, an oracle price feed must be on-ledger for a lending platform to change its rate based on market prices. An NFT’s attributes must be on-ledger for some game logic to treat it differently. 

Bulk data storage for things like images or front-end UI code isn’t that; you would never directly scan a jpeg or try to parse a data file from within smart contract logic running on the network as part of a transaction. All you need (as described in our items #1 and #2 above) is a strong link between the data and an on-ledger representation, and to ensure the data is available somewhere when it’s needed.

That means that storing the data on Filecoin or IPFS or S3 (or even a combination of those things for redundancy) – linked to the on-ledger representation via a hash as described – provides no practical downside at all to the developer. Never does the on-ledger smart contract logic on Radix need to directly access that data stored somewhere else. So why not use a solution that is more optimized for storage than try to force it into the Radix protocol?

Use the Right Tool for the Job

This is why we have no immediate plans to focus on adding decentralized data storage to Radix. In short, there are better solutions out there – and they don't limit what dApp developers can do on Radix. Keeping storage out of the Radix protocol allows Radix to stay really efficient and optimized for secure ownership of assets and decentralized smart contract logic to manage those assets. That’s the real value of decentralized networks and of Radix – and that’s what we want to take to a global scale.