Blockchain – Calling BS On Decentralization & Resilience

by

Since I wrote Flight Delay Insurance – Why Blockchain?, I’ve come across several updates that have reinforced my skeptical views around the claim of decentralization and raised new doubts about the touted advantage of resilience.

UPDATE #1: SINGLE POINT OF FAILURE

Let me take the following remark in my original post:

Data is distributed across multiple nodes, so there’s no single point of failure (apart from the hosting provider of the dApp website, that is). As a result, a dApp is intrinsically shielded from data breaches and inherently enjoys fault tolerance.

As you can see, the highlighted portion is mentioned in the passing. In hindsight, I should’ve been more circumspect about it. Blockchain apps are having an increasingly critical dependence on the hosting provider.

Let’s take Ethereum-based dApps for example.

The Block reports in The Burden of Infura that the “Ethereum blockchain continues to swell in size, with a full archive node requiring 1.8TB space”.

That’s a lot of storage space at the node level.

Likewise, the bandwidth requirement of a node has also doubled in six months.

The combination of high storage and bandwidth requirements has escalated the cost of running a node to $1200 per month.

Apparently the prohibitively high cost has pushed many dApp developers to opt-out of maintaining their own node, and move to hosting provider Infura. Since Infura is a centralized infrastructure owned by blockchain consultancy ConsenSys, it has now now become a choke point.

Since a significant portion of the Ethereum network is based on Infura, most ETH dApps are becoming centralized and subject to a single point of failure.

UPDATE #2: TRUST THE ORACLE

Re. the following line in my original post:

I may not need to trust AXA after fizzy … but I still do need to trust its Flight Data Provider (whoever it is).

Mine is no longer the only voice in the wilderness expressing concern about the pedigree of the external data provider. The Blockchain industry recognizes “oracle problem” – jargon for this challenge – as a major hurdle to the mainstream adoption of smart contracts.

The following passage from MIT Technology Review drives home this challenge:

…before smart contracts can do anything really useful, they need a reliable way to connect with events in the real world—and that has proved impossible so far. This is the so-called “oracle problem,” …

“Oracles” are real-time data feeds that deliver things like weather data, currency exchange rates, airline flight information, and sports statistics to smart contracts.

The idea is that by working together, the two systems can allow blockchain-based services to interact with real-world events with a greater degree of trust than is possible from today’s oracle services. For example, if your flight is canceled but you bought flight insurance, a smart contract might instantaneously pay you after getting an update from a trusted source of flight times.

So what’s the problem? The oracle services introduced to date defeat the purpose of using a blockchain in the first place… (because) today’s oracle services are too centralized… . They represent single points of failure that make targets for tampering.

Ergo, a dApp that relies on an oracle for its basic functioning is not all that decentralized.

UPDATE #3: STORAGE COST

By connecting millions of underutilized hard disks and storage systems in a Blockchain-managed storage mesh, Blockchain-based decentralized storage companies like Storj, Sia and FileCoin promise to drastically cut down storage costs.

According to NSM’s eBook entitled The CMO Primer For The Blockchain World, “Storj already has one enterprise customer in pilot phase and the estimates are that, so far, they will be able to reduce costs of storing data by 90% when compared to AWS.”

However, these narratives conveniently forget to mention one crucial point about the blockchain architecture: A dApp needs to replicate the entire data on all nodes, as against a traditional centralized app (“cApp”) in which data is stored only once – on the central server. This means blockchain apps cause an explosion in storage space requirement. As noted above, a full archive node on Ethereum requires 1.8TB space.

While Storj et al may reduce the cost per gigabyte of storage space, a dApp will demand many more gigabytes. Therefore, there’s no guarantee that a dApp will have a lower total storage cost than a traditional cApp.

UPDATE # 4: CENTRALIZED

The Bitcoin blockchain is extremely decentralized. However, in its native form, it also suffers from a severe scalability problem. One of the solutions to enable the Bitcoin blockchain to process higher transaction volumes is the Lightning Network. However, as The Block reports, “Lightning Network … will lead to centralization to a few large nodes, which will create payment hubs.”. So, for bitcoin to have practical uses, it will have to shed its native decentralized architecture.

Readers of Flight Delay Insurance – Why Blockchain? may have sensed my ambivalence about the claim of decentralization of Blockchain dApps.

By now, I’m convinced that “It’s difficult to be a viable decentralized network when a majority of your applications depend on centralized infrastructure services”, as The Block puts it.

With the passage of time, as the aforementioned updates show, even the claim of resilience is appearing dubious.

With two of its most touted advantages appearing shaky, it’s not surprising that the Blockchain hasn’t set the world on fire.

In what reads like a near-obituary of Blockchain, McKinsey says blockchain has failed to provide “evidence for a practical scalable use” in its essay entitled Blockchain’s Occam Problem.

That’s not to say that all is lost.

Once the legalities around ICO, token, and other thorny issues of the technology are sorted out, I’m very hopeful that Blockchain can be a game-changer in use cases around parametric insurance, loyalty, loan recovery, open banking, metering, and user generated wireless networks.

But, blockchain will have given up its claim of being decentralized – if not also its advantage of resilience – by the time it gets there.

As MIT Technology Review notes, in the context of the indefinite postponement of the recent Constantinople upgrade in its newsletter entitled Ethereum’s latest crisis shows again why decentralization is so difficult, “Ethereum may need to sacrifice some of its beloved “decentralization” if it is ever to achieve its ambitious mission” of becoming a blockchain-based alternative to the web.

For those of you wondering if the centralized versus decentralized debate is purely ideological, it’s not. MIT Technology Review recently pointed out that, if a digital asset is decentralized, the US Securities and Exchange Commission does not see any need to regulate it, whereas if it’s centralized, it will be treated as a security and come under the purview of existing securities legislation. So the debate now has legal ramifications.