Fat Protocols and Value Capture Over Time (Part 1 of 2): Shared Data Layer
If you’ve been involved with blockchain, then you’re probably familiar with the Fat Protocol thesis in which Joel Monegro postulates about value capture in the blockchain era, Web 3.0. He notes that, in Web 2.0 (the social internet era), value accrued to the ‘application layer’ (i.e. in apps like Facebook, Google, Amazon, etc.). Meanwhile, the ‘protocol layer’ — HTTP, FTP, SMTP, etc. — captured little to no value.
Put succinctly, in Web 2.0, applications were fat while protocols were thin. Monegro thinks that value capture in Web 3.0 will be exactly the opposite: applications will be thin and protocols fat. More specifically, “the market cap of the protocol [will] always grow faster than the combined value of the applications built on top” (Monegro 2016). To further understand fat protocol and value creation, check out our presentation and live recording: Understanding Value Creation and Capture in Crypto
Monegro initially floated this argument back in 2016. It was, at that time, an insightful observation and still holds some water today. I remember first reading it and thinking to myself, “okay — that makes sense.” It makes sense to me because I was thinking about Web 3.0 protocols in terms of how the Apple app store captured value: iOS applications sit ‘on top’ of the Apple platform and ‘pay dues’ to the app store. Similarly, dApps sit on top of and pay dues to the base layer protocol. And just like how Apple became more and more valuable as more and more apps were built on top of its platform, it made a lot of sense that base layer protocols would undergo a similar process. It made sense to me that protocols would capture more value than the applications sitting on top of them.
But, when I started thinking about how the trends we’re seeing today would play out and how the space would evolve, it started making less and less sense. Given that protocols today are, in fact, more valuable than their respective applications (because the dApp space is nascent), I can see why protocols being fat holds today. But I don’t think it’ll hold going forward. In the future, the protocol layer will ‘lean out’ and the application layer will ‘fatten up.’ This is shown in the diagram below.
Protocols will lean out because (1) the shared data layer isn’t actually fully shared and (2) stack abstraction will diminish protocols ability to hold on to whatever value they’ve captured.
First let’s talk about the shared data layer.
Shared Data Layer
The shared data layer is essentially a collection of blockchain transactions. It’s one of the main reasons Monegro thinks protocols will be ‘fat.’ As he explains it, the “shared data layer…dramatically lowers the barriers to entry.” This ultimately results in “a vibrant and competitive ecosystem of applications [where] the bulk of the value [is] distributed to a widespread pool of shareholders. This is how tokenized protocols become ‘fat’ and its applications ‘thin’” (Monegro 2016).
According to Monegro, dApps can’t capture data because the shared data layer makes data accessible to all. This is important because proprietary data silos were the thing that allowed Facebook, Google, Amazon, etc. to gain and sustain a competitive advantage. So, without them, Monegro thinks dApps won’t be able to gain — let alone — sustain any type of substantive competitive advantage.
The problem with this logic lies in the fact that it assumes all the data generated by dApps are passed along and stored in a common, shared data layer. This isn’t quite how it works. Though most any kind of data can be stored on the blockchain, it doesn’t mean all data should be stored there.
There are specific types of data that make sense on a blockchain because of the very nature in which that data needs to maintain integrity to prevent one party unfairly cheating over another.
A few examples of data that needs to maintain integrity:
- Account balances — Keep track of account balances; prevent double spending
- Voting records —Secure voting system to prevent corruption
- Title registry — Prevent fraudulent ownership
- Tracking inventory — Track provenance to prevent counterfeit items
The types of data above need to be “tamper proof” and are worth the cost of storing on a blockchain. Because data on the blockchain is immutable, data that needs permanence and can benefit from transparency and trust tend to be good use cases for blockchain.
So, not all data will be treated the same way, there will be data that is effective to be on a blockchain and data that doesn’t need to be on a blockchain because it’s simply inefficient, costly and not valuable for that use case.
Other types of data — social media posts, to do lists, notes, etc. — don’t make sense to store on the blockchain. The cost to store these types of data (especially if this data needs to be constantly modified, doesn’t require trust, or potentially needs to be deleted) isn’t outweighed by the benefit.
That said, there are a select few, highly-specialized blockchains that were built to serve distinct use cases. For example, building a decentralized Reddit is inefficient on Ethereum (gas fees) but Steemit has made blogging and social sharing efficient, assuming you use the Steemit blockchain.
Apart from these exceptions, every time data is written on the blockchain, it requires the payment of a mining fee.
Let’s take a closer look at these costs.
Storing data on Ethereum
Since Ethereum is one of the most popular and used smart contract platforms, I did an experiment to identify the cost of storing 1kb of data on the blockchain. I did this by writing a simple smart contract with about 1kb of data and running it on the Mainnet. The transaction can be found here.
That 1kb of data cost me $1.70. Let’s put this in perspective. An average email is 75kb (this includes html template, logos, header, etc.). The average email would set you back at least $75. That’s unreasonable and completely untenable. We’re used to sending email essentially for free.
These costs disincentive dApps from using blockchain storage more that they have to. They’ll only use it for data they absolutely have to put on the blockchain, opting for different datastores when possible. These datastores can be anything from traditional database like an AWS, MongoDB, etc. to other cloud data storage service.
Datastores: When to Use Which
We know that dApps will use other datastores in tandem with the blockchain. Now, the question becomes which type of data store will be used when. One way this will be determined is by data type.
Consider non-text data, things like pictures, audio, videos, etc. These types of files will be stored in a dedicated file storage system like an Amazon S3 or IPFS (Inter Planetary File System) — the former of which is centralized and the latter decentralized. Non-text data can technically be converted into BLOB (Binary Large OBject) data — binary data — and stored on the blockchain, but this would be prohibitively expensive. Microsoft’s To BLOB or NOT To Blob explores this cost vs. convenience tradeoff between when to store data in BLOB form in databases vs. file systems.
In short, BLOB data less than 256kbs is fine on a database server while file storage systems are best for anything above 1MB. That said, 256kb is, in and of itself, unreasonable for the blockchain. It’s likely that anything close to this size will end up being stored in file storage systems.
As dApps make use of non-blockchain datastores, the blockchain ecosystem will transform, as shown below.
While blockchain scalability remains to be an issue and as other platforms are emerging, most dApps will continue to use hybrid like approaches until it becomes economical to put data on a blockchain.
Summary
The shared data layer is generally misunderstood. Data on the blockchain will be a lot more fragmented than the “universal shared data layer” that Monegro describes. This is because dApps have control over the user experience and, thus, get to dictate what data is stored on the blockchain and what is stored elsewhere.
In part two of this post, I’ll dive into how stack abstraction above the protocol layer impacts the blockchain ecosystem, making protocols leaner and leaner over time.
Thanks to my colleagues Joel Camacho and Harshitha Kilari for the feedback on this post.
Disclaimer. This post is intended for informational purposes only. The views expressed in this post are not, and should not be construed as, investment advice or recommendations. This document is not an offer, nor the solicitation of an offer, to buy or sell any of the assets mentioned herein. All opinions in this post are my own and do not represent, in any manner, the views of Decipher Capital Partners or affiliated companies.
