The Blockchain Dilemma

Michael Coon
Coinmonks
7 min readMay 13, 2018

--

I have had several questions at various meetups and panels around why a company would choose to use blockchain over, say, web services or a normal REST-based application. In particular, if the idea is to make things transparent and open, how does a company selling user data benefit from such transparency? I thought it would be good to share some of my thoughts and answers to this critical question.

D-Apps

First, let’s define more broadly what a blockchain application is today. Blockchain is moving beyond its financial ledger beginnings to an ecosystem for building decentralized applications, or D-Apps. A D-App leverages a blockchain backend to access some shared state. The app’s primary benefit is leveraging blockchain’s transparency, consensus, and verification mechanisms to provide a trusted environment to transact.

Let’s start from a common scenario that drives many businesses today. Suppose a company, let’s call it ReciShare, creates a recipe sharing app. ReciShare’s mission is to personalize and simplify finding and sharing recipes. Its business model is to monitor user interactions, learn what types of food each user enjoys, and sell that data to marketing companies that might offer coupon and food ads to the users. To create the app, ReciShare uses AWS to host a MongoDB datastore along with a Node.js server that handles interactions from a mobile app.

This is a pretty typical setup in today’s data-driven marketplace. So the obvious question from these companies is, “why does blockchain matter to us?”. What benefit would this company realize through decentralization, transparency, and transacting in a trustless environment?

Decentralized Infrastructure

First, consider the infrastructure. Since the application uses AWS, access to the recipe data could be shutdown. Why would it be shutdown? Suppose that some of ReciShare’s users live in a part of the world where certain ingredients are not “socially acceptable”. Other parts of the world might ask that the recipes be removed or that the service be shutdown because of its offensive nature. As a centralized company using a centralized infrastructure, can you see that either ReciShare or AWS could be compelled to comply? Infrastructure matters in social apps like this because not everyone will agree on what is socially acceptable. For the D-App to succeed in a global ecosystem, it must include a community-driven mechanism that determines what the D-App exposes to its users. But how do users know what is being exposed?

The desire to gain public consensus on ground truth is what drives the majority of blockchain ecosystems

Transparency

Transparency is a critical element to blockchain and D-Apps in general. The desire to gain public consensus on ground truth is what drives the majority of blockchain ecosystems. Since the datastore is walled off inside AWS/MongoDB, there is no way of knowing what ground truth is for the recipe data — the users only see what ReciShare is willing to deliver through their mobile app. And it’s not just the recipe data that’s of interest to decentralized users; what does ReciShare know about its users and what is the company doing with that information?

The Dilemma

This creates a dilemma for ReciShare, and companies like them. Their entire business model revolves around selling user data, and they need to protect the data if they expect to continue generating revenue. They also have to protect themselves against legal action due to offensive content. At the same time, maintaining their current practices is a gamble on whether consumers will demand uncensored transparency from products like theirs. They also risk losing customers to competitors that offer incentivized alternatives to free data sharing. ReciShare wants to mitigate these risks while still maintaining their business model — what do they do?

The most challenging part of migrating to blockchain is the mental shift from being data “stewards” to “facilitators”.

Blockchain Social Engineering

Blockchain is very much about social engineering — incentivizing good behaviors and dis-incentivizing bad behaviors. ReciShare wants to incentivize recipe sharing and searching since that is what drives their business model. They want to dis-incentivize sharing offensive content because that will get them sued. The most challenging part of migrating to blockchain is the mental shift from being data “stewards” to “facilitators”. Stewards must maintain clean, filtered data. Facilitators, on the other hand, merely maintain an environment for accessing clean data. The shift is like going from merely being an app, to being a platform for other apps. ReciShare has to go from simply owning data, to providing a platform for data sharing to happen. But how can they be transparent and still generate revenue?

Utility Tokens

Blockchain economics is all about knowing how to incentivize behaviors that are beneficial to all participants. In ReciShare’s case, they have to incentivize data sharing while dis-incentivizing bad content. But what is considered “bad content”? Who makes that decision? What actions are taken when something is considered “bad”? This is where creative social engineering has to happen and ReciShare might take advantage of a “token” system.

Tokens in blockchain are becoming synonymous with raising capital through ICO’s; but the real benefit of tokens is in their social engineering utility. Yes they can have monetary value if they are tied to some form of value exchange; but earning these tokens becomes part of a game within an application. ReciShare could incentivize sharing by offering tokens as rewards for sharing recipes. It might then make these tokens part of a voting system whereby token holders determine whether content is removed from the platform. The economic model might be 1-token-1-vote or a weighted model where “wealthy” token holders cannot overrule majority voice. The beauty in engineering a system like this is that the role of ReciShare is more like a governing body allowing its users to act in a more collaborative way. This forms a kind of partnership with ReciShare customers and voting might go beyond content exposure — customers might have influence over the direction of ReciShare itself! This is what is known as a Decentralized Autonomous Organization (DAO) and is of great interest to the blockchain communities.

Customers as Partners

But what about ReciShare’s business model? It is possible that through this partnership with its users, ReciShare offers its users the option of sharing their data in exchange for tokens? Each user’s data is ultimately tied to an ID — even in ReciShare’s legacy approach, selling data needed to be tied to a specific user to target them with coupons/ads. Because that ID can be tokenized and associated with a blockchain address, each purchase/access of information associated with that ID can be recorded and rewarded in real time. Perhaps the ads themselves can be tied to the ID and if the user views the ad, the advertising company pays them a viewing fee. This model makes things much more transparent and earns ReciShare a tremendous amount of trust with its customers. This also offers a new potential market and revenue stream for ReciShare: public analytics. Suppose ReciShare users want to earn more tokens. They decide to mine the publicly visible, anonymized user data to create market demographic reports. These reports can be sold as part of ReciShare’s data offerings and the revenue is split with the report authors. There are many unforeseen benefits to making things transparent when ReciShare decides to partner with their customers.

…decentralization enthusiasts can still accept semi-centralized apps so long as they support the philosophies of blockchain: transparency and democratized consensus

Infrastructure?

Many of you may have noticed that I didn’t really address a way around the centralized infrastructure running in AWS. Most of blockchain’s draw stems from its mesh-like network of peers communicating without the possibility of being shut down. And with smart contract networks like Ethereum and Neo helping pave the way for more functionality built on top of blockchain, it seems plausible that we can eliminate centralized infrastructure like AWS.

Unfortunately, we’re not quite there yet. There are still some drawbacks to the current offerings. Storage costs, reliability, and speed are not yet where they need to be in order to build fully decentralized apps that are performant and user friendly. Technologies like IPFS, Ethereum Swarm, FileCoin, and Storj are all attempting to address distributed storage in their own ways; but none of these have matured and/or materialized to the point where there is a clean, easily integrated, and performance-optimized way to store and retrieve data from a decentralized network of data-sharing peers. And even though raw storage in Ethereum smart contracts is extremely easy to do, it is so cost-prohibitive that it would never make sense to implement. That is not a slam on Ethereum smart contracts — this is a conscious design decision to minimize the amount of data copied around the network. I’m merely pointing out that storing data in a contract is very easy — and one day, it will be just as easy for the various storage solutions being built today. Until then, I believe some centralization will be necessary. But decentralization enthusiasts can still accept these semi-centralized apps so long as they support the philosophies of blockchain: transparency and democratized consensus.

Summary

Blockchain ecosystems are attracting a consumer base that is motivated by transparency and collaboration. To participate, traditional business models may need to shift towards a customer-partnership model that includes democratized influence and profit sharing. By allowing customers to participate and share in revenue, companies can more easily become decentralized and collaborative entities driven by the users that ultimately form the basis of an application’s value. Building these applications is getting easier; but still requires some insider knowledge to understand how to integrate legacy systems with decentralized networks. I would love to hear how others are helping companies make the shift!

--

--

Michael Coon
Coinmonks

Blockchain enthusiast, smart contract wizard, seasoned software engineer, personal development junkie