Blockchain and the Goldilocks Dilemma

Edwin Olson
4 min readAug 22, 2018

Blockchain, or more broadly speaking, the idea of a decentralized ledger of transactions whose authenticity and authority are established by a community of users, is pretty darn appealing. Cutting out unnecessary middlemen seems like a big win, particularly if those middlemen are corrupt, incompetent, or simply have goals that are in conflict with the users themselves. Decentralized ledgers appeal to our basic sense of fairness and democracy, where the “little guys” have power and autonomy.

The problem is that blockchains don’t achieve these goals, and the root cause is a fundamental “goldilocks” dilemma:

  • It must be attractive for a user to participate in the blockchain. Broad participation by a diverse set of users is protection against fraud and manipulation. Unfortunately, many blockchain applications are doomed because they do not create enough incentives for participation — those applications are “too cold”. As a result, the blockchain is vulnerable to bad guys with modest resources.
  • If it is too attractive for a user to participate in the blockchain, users with substantial resources will attempt to gain an unacceptable amount of control, which creates opportunity for manipulation and fraud. Those applications are “too hot”.

Virtually every application of blockchain fails to land inthe “goldilocks” incentives (not too cold, not too hot) required for a healthy distributed ledger where power remains decentralized. It remains to be seen if any application can fit this bill.

The canonical application of blockchain is currency, e.g. BitCoin. Manifestly, the problem here is that the incentives are too hot; everyone understands the value of money, and the market has attracted the resources of powerful users. Whether a 51% attack is possible in the short-term is unclear, but it is clear that the market is that power is not decentralized. (It’s also clear that the currency markets are being manipulated through other mechanisms to benefit those large players, but that’s a different article.)

Another recently-proposed blockchain application was tracking the repair history of automobiles. The idea is nice: create a distributed history for every car, where any buyer or seller can verify the repair/accident history of a vehicle. The problem is that there are few incentives to encourage large number of users onto this blockchain. Why should anyone spend their CPU cycles on this? Most of the time, most people are not thinking about repair/accident history of vehicles, and when they do, there are other ways ways to learn about the car… (One imperfect but pretty good method is the walk-around and test-drive.) With low user participation in the blockchain, an unscrupulous car dealer could focus resources on forging transactions; a few dollars of AWS time and they could literally rewrite the history of any vehicle. In other words, the incentives are too cold to attract the users necessary to block a rogue dealer with a paltry budget.

Perhaps self-driving vehicles could use blockchain to share information about the position of other road users? Even setting aside the practical problems of latency (i.e., knowing where a pedestrian was 2 seconds ago is useless), this is insanity. Even though every car in a small geographic area has an interest in the proper operation of the protocol, the incentives are far too cold. Much like the unscrupulous car dealer, a rogue car could easily overwhelm legitimate users in order to inject arbitrary information into the blockchain. Real physical damage and injuries could result.

Some applications are failures because they simply don’t need a distributed blockchain at all. Some companies have proposed blockchain-based gift certificates and frequent-customer promotions. These are silly because the very nature of the transactions is centralized around the company in question. They would be better served by a well-maintained centralized database.

One could argue that mixing many applications into a single block chain makes it easier to balance incentives. However, there are real costs to every transaction in a blockchain. If some transactions are hot (e.g. financial transactions), it will naturally push the transaction fee higher, making transactions too expensive for lower-value applications (e.g. car repair histories).

There are technically fascinating ideas within the blockchain world; the original BitCoin work had multiple “wow, that’s clever” moments: proof-of-work, auto-adjusting difficulty, and the distributed consensus algorithm. Proof-of-space, smart transactions, etc., have all piled on additional Eureka moments. There is an emerging science of blockchain ideas. Perhaps, if we can mix the right pieces together, in the right proportions, we will get gold?

It wasn’t that long ago that scientists started understanding how chemicals could be mixed together to create new substances. They, too, were pursuing gold. Today’s blockchain developers are a lot like alchemists, trying to create gold from algorithmic building blocks; but a solution to the Goldilocks problem seems out of reach.

Postscript: The lack of a “Goldilocks” zone seems to arise from the linearity of rewards in blockchain mining. Let’s suppose that you find it worthwhile to use an hour of computer time to mine $1. If you put in 100 computer hours, you get $100, which you presumably also think is worthwhile. Unfortunately, if it’s worthwhile for an individual person to participate in the blockchain in a modest way, it’s probably worthwhile for a powerful user to try to monopolize the blockchain.

If, on the other hand, if a user’s rewards scaled logarithmically (e.g. you get $1 for one hour, $2 for 10 hours, $3 for 100 hours, and so on), it would encourage many people to participate at the one-hour level, but nobody would spend 1000 hours to get a measly $4. But it’s unclear that you could ever implement such a reward system — the powerful user could simply pretend to be 1000 different people, each using only 1 hour each, then getting the full $1000.

--

--

Edwin Olson

CEO of May Mobility, Professor of Computer Science at University of Michigan