Needles in the Blockchain Haystack

Finding enterprise use cases worth development dollars

Earlier this year, the GSMA, the world’s most influential telecom consortium, published a paper detailing fifteen blockchain use cases for mobile network operators. Some of them were compelling. Others, less so.

As an entrepreneur in the telecom and blockchain space, I was happy to see this kind of attention given to my still-nascent field. (Is all press good press?) But as a founder whose ability to buy Chipotle burritos rests on how seriously and successfully telecom carriers adopt blockchain technology, the addition of those less compelling use cases had me worried.

The sad truth is that the blockchain world is rife with misinformation, poorly-thought-out applications, and centralized tech pretending it’s “de-”. If left to their own devices, I could imagine carriers attempting the use cases I saw as less promising and being forever turned off of blockchain.

So, although it’s against my very nature as a native Midwesterner, I see no other alternative to raining on this particular parade. As Warren Buffett wisely said in his '17 shareholder letter:

The less the prudence with which others conduct their affairs, the greater the prudence with which we must conduct our own.

In this article, I’ll attempt to be a voice of prudence. The applications that the GSMA proposes range from great and world-changing to fundamentally flawed, and I’ll explore four of them in the sections that follow. In so doing, I’ll draw out lessons worth remembering not only in telecom but also in broader enterprise blockchain R&D.

A quick note on methodology: as an IDEO CoLab Fellow last winter, I learned that new tech is most interesting when it is desirable (i.e., adds real value for real people), feasible (i.e., technologically possible), and viable (i.e., good business). Check out IDEO’s explanation here if you’re curious, but it’s easiest to just witness them in action. You’ll get it.

#1: Smart contracts for 5G network management

“To realise the 5G promise of ubiquitous access across various networks, CSPs will need to handle heterogeneous access nodes and diverse access mechanisms. Selecting the fastest access node for every user or machine will be a central challenge in the future. …Rules and agreements between the various access providing networks can be coded into autonomous smart contracts. These contracts can be dynamic in nature wherein any time a policy needs to be changed, only the contract code needs to be changed.”

The GSMA’s first use case falls prey to a classic problem of outside-in entrepreneurship — it describes a solution that every consumer wants but no business will offer.

Is it desirable to connect to any network freely and get the best value for the best service? Of course! I don’t care who gives me four bars of LTE service as long as I can reliably stream the #7-ranked Michigan basketball game in the back of my Uber.

But from the carrier’s point of view, this solution is neither feasible nor viable.

On the technological feasibility side, the use case makes a number of critical leaps into still-unknown areas of blockchain tech, but far more damning is the business viability critique: why would carriers ever give up control of their customers? Carriers have built empires by leveraging their network assets to attract customers and reduce churn. Would they really buy into a protocol that forces them to auction for every data session, text, and call?

The lesson here is for prospective entrepreneurs: keep the enterprise in mind when designing enterprise blockchain products. Sounds tautological, but it’s surprisingly easy to forget. Yes, real-time bidding for connectivity would be amazing. But if it ever exists, it will only be after a prolonged battle with operators the world over.

#2: IOT connectivity

“While localised networks in for instance a manufacturing line can provide great benefits, self-organised global supply chains powered by IOT can help streamline processes that require a lot of paperwork and governance. This would shift the focus from centralised IOT platforms (in technology and governance) to self-governed mesh networks… IOT can also be used for automatic tracking for quality and conditional parameters during transports, switching of ownership and provenance use cases.”

The GSMA offers up three use cases in the IOT space. Unfortunately, they all fall prey to the same problem — they’re smart, and should probably happen, but they probably shouldn’t happen on a blockchain.

These use cases are feasible: IOT management via blockchain is a use case well-explored by startups and large enterprises alike. They may even prove to be viable: IOT is a huge and growing industry, devices will get smarter and smaller over time, and managing devices efficiently is a huge, valid concern.

The problem arises, though, when we consider the desirability of blockchain in this context given the problems we are asking it to solve.

As I understand it, the problem is that we can’t get good data about products flowing through a manufacturing line or a multinational supply chain, so we’re asking blockchain to help. Walmart, for instance, now mandates that farms that supply their stores leafy green vegetables enter “detailed information about their food into a blockchain database” that they’ve build in conjunction with IBM.

But wouldn’t that “detailed information” be just as useful in a normal database?

In my mind, this type of supply chain management is a poor use of blockchain. If you can’t trust your supply chain partners (or much less, the folks on your manufacturing line) to produce accurate data, it doesn’t matter whether you use a blockchain, a database, or a stone tablet to store it: your customers are still going to get E. coli from your lettuce. Garbage in, garbage out. (Or, due to blockchain’s immutability, it’s more like garbage in, garbage forever.)

The lesson here is never to use blockchain when a normal database will do. Blockchain is expensive, slow, and non-private. It costs significant time and resources to write to a blockchain. Barriers to entry are high. (Do Walmart’s farmers now have to own wallets or accounts with IBM?)

This is not to say that blockchain won’t have a place in IOT; I think it will. But I’m willing to bet that device security turns out to be a better use case than provisioning or self-maintaining supply chains, because the former is a better fit to the unique constraints and benefits of blockchain.

#3: Fraud prevention

The telecom industry has not yet found a way to effectively and sustainably prevent fraud. In a general sense, working together to combat interoperator fraud is a good way to start. Blockchain could for instance be used to govern access to fraud detection information shared between operators…another angle is fraud caused by delays in sharing [call detail records] between operators. As blockchain works in real-time, using a shared administration of network activity could help identity plausible fraudulent connections faster. Smart contracts could be deployed to actively enforce network usage compliance rules and help us resolve inter operator disputes easier.

Surprise twist: I actually like this upcoming use case! In fact, I like it so much that I’ve been working on it for the past year with drect.ly. (Is that cheating?)

From a desirability standpoint, blockchain has some clear advantages over other solutions in fraud prevention. In fact, it’s so good that you get to (justifiably) recite the holy text of blockchain use cases:

This is a case when mutually-distrustful actors need to coordinate to maintain a shared version of the truth for an economically-valuable digital record.

That sentence is why blockchain was created; in this use case, we’ve just replaced the economically-valuable digital record of bitcoin ownership to a record of which telecoms have provided how much coverage to which roaming customers.

Those records, it turns out, are incredibly valuable (and therefore, if managed well, can sustain a viable business model). Every year, telecom carriers lose over $38 billion to fraud; even a relatively small dent in that number is large in absolute terms.

My own incredible bias notwithstanding, I do recognize some challenges here with feasibility. Billions of records are exchanged daily, which poses scalability problems. These records expose significant, closely-held data about network usage and subscriber behavior, which poses privacy concerns. Governance is challenging, for it’s unclear how centralized my ownership of the code base makes this project. And how can you get bad actors to sign onto a platform that demands higher responsibility?

All that said, these are solvable problems. And perhaps that’s another lesson: ensure that your use case is a great fundamental fit with the unique value prop of blockchain technology — and then prove the feasibility haters wrong.

If you think about it, that’s really the only way that any technology advances.

#4: Hosted services

Distributed Ledger and/or Blockchain network operators are responsible for configuring the network and granting access to network participants. In general, they specify the use case(s) that the network is serving, and are often involved in managing the network in terms of software upgrades, arbitration services, etc. A network can be operated by a single entity or a federation of multiple, separate entities.

As a strategy consultant at Deloitte, I helped write a trends report on ecosystems thinking. It generated over 100 million views before being lost to the sands of business-thought-pieces past, but I’ll always remember it as the first time that I learned John Hagel’s concept of innovation “antibodies.”

The SparkNotes version of Hagel’s idea is that antibodies (i.e., agents of resistance) arise in big organizations whenever change is coming. They fight for the preservation of the status quo that helped them rise to power, and, even if well-intentioned, they often stifle the speed of change by insisting that old rules, norms, and values govern fundamentally new contexts. For example, a new business unit might be shut down because it’s cannibalizing sales of the core product; that is judged by the old rule of “protect the core,” rather than the new reality that any player could release the cannibalizing product and it’s better to optimize for growth.

In the blockchain context, antibodies take the form of centralized services masquerading as blockchain technology. In the old world, businesses want efficiency and control — but Proof of Work is deliberately inefficient, and blockchain networks are intentionally decentralized. When I read a use case like the “hosted services” from above, where blockchains are treated like permissioned databases, I can’t help but remember Hagel’s antibodies.

The whole point of blockchain technology is to make public commitments that are impossible to reverse; to open up previously siloed networks; and to radically decentralize power, code, and economic value accrual.

So, my final lesson is this: never surrender decentralization when designing blockchain use cases. You’ll want to do so — believe me, as someone who has built these systems — but if you do, you’ll be further from the real promise of blockchain technology and closer to designing a really bad database. After living in a centralized world, decentralization feels innately wrong. But as we enter this new age of decentralized technology, we ought to remember that it’s okay to break all of the old rules.

In fact, that’s the whole point.

To connect with Christian, reach out on Twitter (@cdkeil) or via email at christian [at] drect.ly.