Ok, maybe the intentions of the coffee consuming community are evolving toward needing to know who grew the beans. I don’t know. Seems like a nice thing to know, but I’m not walking out of a cafe that can’t tell me where a specific bag of beans came from. I’m content to know that they buy from so-and-so. They’re welcome to paint that on their wall in some cool font above the bar, and I might be pleased to read it while I wait for my brew. But it’s not going to significantly change my behavior.

There was, indeed, a change of intentions happening, but it wasn’t what the evangelist was claiming. The change was that the blockchain company demoing the solution was able to use the bean grower’s intention to get greater brand exposure:

“Hey, I know you don’t like to share your company’s data, but if you put some of it in this shared database we call a blockchain, I’ll put your brand in front of thousands of executives in Vegas…I’ll even put you-yourself on stage with our CEO.”

The bean grower then might have asked, “Why would anyone care about our supply chain information?” Normally, nobody would. You can’t get 30,000 people to show up to a presentation about putting stuff into a database, but while the world approached the blockchain peak of inflated expectations in 2017 and 2018, you could do exactly that for a database called blockchain. Try that later in 2019 or 2020 and see what happens after the sweet taste of new new blockchain sours, and it becomes the last thing people want to talk about. Welcome to the trough.

The lesson: Do blockchain and web3 projects that are notStupid. Because if you don’t, you will only be adding to the skepticism of your team (and you) that the whole thing is “just tulips,” a fad. Then you will join the ranks of the too-early adopters and be forgotten.

Safe is Dangerous

Another big lesson is less obvious in the coffee case, but here’s what often happens. A company decides it wants to learn how to spell blockchain. Leaders are only mildly interested, but a few wild ducks in the company can’t stop talking about it. So a small budget is allocated to do a “POC” and explore a “use case.” Typically, this thinking sets a key project parameter implicitly: do something easy, do something safe.

Oddly, doing something safe is the most dangerous thing you can do at this stage in blockchain. It results in deciding to do a project that covers ground you have already covered with previous systems, known territory.

The problem with covering a known use case is that your conventional systems have been tuning for it over many years. Blockchain, in its current state of maturity, will fail along virtually every measure of performance and functionality compared to what you already have.

Imagine it’s 2009 and you’re building the first ridesharing app. In 2009, you can build a minimally viable product that does nothing more than paint cars moving around on a second-generation iPhone screen and let the user dial a dispatcher by touching the nearest car. In 2009, people lost their minds over just that, proving that showing the live position of your ride on your phone mattered to people. But imagine building that same “MVP” today. People would hate it. “What’s a dispatcher?” they will ask. “I can’t hail the car? I can’t phone the driver? I can’t pay for the ride with the app?? This thing sucks!” Today your experiment fails…for the wrong reasons.

Since 2015, I’ve seen and been involved directly in many so-called blockchain projects that failed due to “pave the cowpath” syndrome. We built what the company asked for. Everything worked. The demo went off without a hitch, and then the notStupid executive reviewing the project inevitably said, “Right…thank you very much. That’s a nice little project there. Goodbye.” And that was it.

The Lesson: Do projects that are just as, or even more, compact and simple as the “stupid” coffee project, but make sure they are exploring new territory. AND make sure that the territory being explored has a good chance of revealing a game-changing new opportunity that would be too good for the company to pass up, if proven. Build the 2009 ridesharing app that opens peoples’ eyes to the possibilities, not the 2019 poor-excuse-for-an-Uber-clone.

Spend the small amount of extra time getting rigorously creative about the project before choosing the dangerously safe option, and you might find a notStupid use of blockchain.

notStupid Uses of Blockchain in Industry

There really are some notStupid uses of blockchain and related technology (Web3), and there will be a lot more soon.

I didn’t find as many projects out there on my “30 day notStupid Enterprise Blockchain Challenge” as I had hoped. But I did find a few, and they highlight good principles to develop more. For example, CLS completed a project recently that stands up to at least one of the criteria below, though not all.

A notStupid use of industrial blockchain starts with the right intentions:

There must be more than a few legally-separate parties that intend to collaborate for reasons that will persist beyond the honeymoon period, usually to overcome a problem or capture an opportunity which is — or can be — financially material or strategically significant to them; The parties must intend to control their own part of the infrastructure and prevent any other party having administrative or hegemonic control over the system or the business rules; The parties must intend to achieve true tamper resistance of the data, which means that they can assure anyone that they did not collude to tamper with the ledger, alter business rules or censor transactions;

[Note — a private permissioned “blockchain” between, say, a few banks can not claim true tamper resistance unless they are using something like Chainpoint or Kaleido to hash (notarize) state to a mainnet like Ethereum or Bitcoin.] The parties must intend to maintain surveillance resistance, ensuring that confidential business rules and transactions are not only kept private but their existence is known only to the involved parties, which means some parties even inside a permissioned private network must not always be able to see what other parties in the network are doing; The essential data involved must be novel digital assets.

This last one is critical and deserves explanation. Using blockchain simply to share information, like the date your bananas showed up at a port, isn’t going to cut it. Is it a good exercise to start with? I’d say no, but maybe it’s ok, if there is a strong commitment to ignore the results of the POC and move immediately on to something more powerful that fits the criteria above.

However, if parties are trading digital assets, which must be proof against double-spend, then employing some kind of blockchain starts to be notStupid. And it becomes essential when:

The assets are too sensitive or valuable to trust their management to any one entity, even a joint venture;

The volume of trade rises to a point where participants begin to worry about the power they will be handing over to a controlling entity;

Achieving a new degree of fluidity and inclusion drives the need for tiny and free-flowing trades between a wide array of parties, not just a few enterprises;

The parties intend not simply to move inert assets around but to use novel asset structures to change incentives and alter the game in their industry.

If you aren’t exploring ways to change something about the game rules of your industry, then the probability that your intentions require the use of blockchain technology is low.

It’s the Internet, Stupid

Starting in 2019 or 2020, blockchain and related infrastructure (Web3) will begin to support these intentions. This is when we will begin to have an always-on, universally accessible infrastructure, an evolution of the Internet, which can allow parties to:

Quickly look each other up on a global registry (ENS?);

Instantly spin up an on-demand virtual sidechain;

Make secret but final transactions;

Conduct confidential agreements that can seamlessly interoperate with code on other sidechains and mainnets;

Do this without exposing confidential business rules or transactions to each other or the public.

Can you set up a private network or use blockchain-as-a-service offerings to create a shared database for a consortium today? Sure. But it’s akin to setting up an Extranet (remember those?). It’s doable, but the sheer effort and time involved simply in organizing the parties manually raises the bar to the level of effort that begs the question: why not use conventional systems with tried-and-true security and fine-grained access controls?

The difference between the soon-to-be “stateful Internet” and today’s enterprise blockchain networks is like the difference between companies collaborating via public APIs and SDKs (like a ridesharing app using Google Maps) and companies spending months to negotiate a strategic partnership.

If you can justify the effort of setting up a private, balkanized consortium blockchain, then you probably didn’t need blockchain. And this will be especially apparent after blockchain loses its ability as a shiny object to attract membership.

Patterns and Suggestions for notStupid Projects

Here are some cases, lessons and patterns I picked up on my quest to find notStupid enterprise blockchain projects last month.

Through 2019, my team at ConsenSys Web3Studio will publish more real cases with real code and great documentation. If you want to explore ways to change the game in your industry with us — or at least become a good story in an upcoming book on the subject — reach out…we’re easy to find.

Start with conventional technology & focus on game design

The smartest use of industrial blockchain I saw this year — a venture capital network called Coven— ran for several months on an Excel spreadsheet. Their focus was on tuning the incentives of different players and making it a better game that organically helps deal finders, reviewers and investors be more aligned, fluid and accountable.

While this operation was testing out scenarios on very small deals with very small numbers of investments, Excel and Slack were not only more-than-adequate as the system of record, they were essential. It forced the team to focus on mechanism design, the game. And it allowed them to get the business rules (which ultimately will become immutable smart contracts) correct and tested before deploying them on a blockchain.

Once they got the basic game stable, and as the deal sizes and volumes increased, going to a web-based SaaS application with a traditional database sufficed for a while. But now, as things really start to expand, participation increases, and assets become seriously material (and as making a mistake with them becomes a major liability), the need for the judicious use of blockchain is apparent.

This is also a good example of how blockchain shouldn’t be the centerpiece of a Web3 project. Here, most of the system that lets users log on and find deals will always be SaaS, but the component that manages keeping track of who earned what and transfers assets between parties will be (must be) done on something like a blockchain.

Here is a key theme I suspect we’ll be seeing through 2019 and 2020:

This project really needs the surveillance-resistance of a private blockchain (really of a traditional, well-administrated database) while also removing the organizer from the liability of maintaining the system and ensuring the integrity of the ledger.

It needs a stateful Internet, one where not only strong privacy but also strong confidentiality (data and code-execution segregation) can be ensured. They can’t simply put the private dealings of investors and stealth startups directly on one of today’s public blockchain mainnets, the digital equivalent of nudist colonies. Nor can they maintain private ledgers they control without becoming a single point of failure and incurring a lot of risk — risk that will result in high fees gumming up the system and turning the whole affair back into the same old game they were trying to change.

I can’t speak for the organizers of this project, but I expect that this kind of pattern will proliferate when we have proven out sidechain technology like Plasma/Layer2/etc…and especially when virtual on-demand sidechains can be spun up across millions of standing edge devices running secure enclaves and other fancy tech. (See this story for one vision of this.)

Standards before Networks

An industrial-strength version of the venture capital case is starting to form around the Enterprise Ethereum Alliance (EEA), a large body of companies trying to develop standards for Web3.

The urge for many middle-managers asked by their boss to “do something with blockchain,” is to set up some kind of network, maybe concoct some kind of “wallet” for employees to tinker with. Meh.

But for some companies — Oracle and SAP come to mind — they have the ultimate examples of well-researched industrial game designs that have been operating for years. Oracle Apps and Ariba have long managed the rules of many industry games, albeit using conventional technology.

They could now start “paving the cowpath” and standing up blockchain networks as poor approximations of these powerhouse industry applications.

Or instead, they could first write standards based on these apps — from complex business logic to the simple standard that says, “Use fName, not firstname, as the field for a user’s first name.” They could bake these into something like an ERC (Ethereum Request for Comment) and promulgate it through the EEA. Then any new networks, subnets, sidechains, etc. that launch in the future can be confident they can interop with any other system that implements the ERC.

CloudCoin

Here’s a good example of how the community’s intentions are already changing as a result of blockchain and Web3 principles rising. There are already cloud computing customers asking to spread their data, compute and bandwidth across multiple clouds, so that no one provider has enough customer information to result in a data breach if hacked.

But they don’t want to have to manage multiple clouds and get multiple bills. As this customer intention rises to become a real market, smart cloud providers will be able to make more money together than on their own. And I’ll predict that today’s second-tier clouds will start the game working together, because they will see the opportunity to out-scale the leader. I don’t know if it will be called “cloudcoin” (someone has that URL), but expect this to be a thing in the next few years.

Blind Transparency

The pattern that really makes sense to me for industrial blockchain (and again, requires this hybrid “public/private” infrastructure) can be described this way:

Three companies walk into a bar. They all need to know that none of them are too drunk to drive home, but Company A can’t know that Company B just bought Company C a drink.

Ok…that might make no sense on its face, but I think it’s hilarious. The sober way to explain this is to consider all the cases where companies need to get a verified signal that everyone agrees is important for the whole industry, but where nobody should have access to the information required to generate that signal.

Take medicine: Preventing participants in clinical trials of new drugs from joining more than one study is kind of important. For one thing, taking more than one experimental drug will probably kill you. And for another, it will invalidate both studies. The trial organizers (the drug company and others) need to know you aren’t in another study when you show up, but they can’t know anything about anyone else’s study, for obvious reasons. We can’t publish a big Google spreadsheet and have everyone list their trials and participants.

If an industry can trust a single entity to be the black-box of this information, then the problem is trivial. And indeed, for this problem, a company called VCT does the job.

But think of all the problems that fit this pattern in your industry that simply don’t rise to the urgency of the VCT case. (And while I haven’t spoken to the leaders of VCT…yet…I bet they had a jolly fun time getting companies across the globe to participate. Bet it took years and cost them millions.)

Advances in Web3 technologies should enable a low-cost, universally available, tamper resistant black-box where no human has access to the information that generates, say, a true/false signal based on a query.

Think what you could do with that.

VIA: Value Introspection and Attestation

Ever have to deal with VAT tax? It’s a hassle. Value added tax — common in Europe — means you have to keep track of all the stages of manufacturing and distribution of a product. You don’t just tax the item at point of sale once. You hit everyone that contributes something to the finished good. What a nightmare.

But in a mature stateful Internet, the matter can become trivial (assuming we are talking about a pervasive and precocious regime where buyers and suppliers are using and integrating workflows with blockchain the way they pass messages via email today). Each step can be treated as an asset, which is part of a composition of assets that make up the actual product.

Imagine this pattern applied in more novel ways than tax. What if a buyer of a dress could tip the person who sewed the dress without a supervisor finding out and trying to garnish it?

Have a few drinks and ponder this one.

Post-Coasian Companies

There are other patterns and cases that I turned up, but here’s the last one for now, and it’s the most radical.

Ronald Coase published his theory of the firm in 1937, arguing that founders decide to organize into firms to avoid search, contracting and other transaction costs necessary if they organized as a market. (Please feel free to quibble with my paraphrasing.)

With modern IT and Web3 rails, it is conceivable for some genius, Will Wright-like founder to construct an efficient market game for their firm…or even a cluster of firms operating in a mesh. Everything (or most things), including leadership, becomes an atomic service. You can contract with me for “this is the guy to call if you have a problem with me that you can’t tell me about directly” services. What if the daily scrum became the basis of how everyone’s bonus were calculated? See this experiment for details.

Crazy? Maybe. Happening now? Yep. That’s why I like working at ConsenSys.

What do you intend to do?

Innovation is a sentence constructed of nouns and verbs. Inventions are the nouns. Intentions are the verbs.

A bunch of people are building a magic pencil called Web3 that has a sharp black tip called blockchain.

The question for 2019 and beyond: Are you going to leave it there on the table, write something with it, or stick it in someone’s eye?

The next time you ask someone to help you figure out “this blockchain thing,” keep an eye on your intentions and how they change as you figure out what this thing can do.

Work in Progress

This article will undergo ongoing upgrades. It is decidedly not yet a notStupid version of the blockchain story. Help make it better. Thoughtful comments are not only welcome — they will be gratefully read, considered, and followed-up.