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:

Let me take the following observation 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 the role of the hosting provider. Blockchain apps are having an increasingly critical dependence on the hosting provider now.

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:

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 of concern in the wilderness about the provenance 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.

Let me quote a few passages from an article in a recent edition of MIT Technology Review to amplify this challenge:

QUOTE

...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.

ENDQUOTE

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

(https://twitter.com/notgrubles/status/1084626956862279680)

UPDATE #3:

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, this exuberance about cutting down storage costs misses 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") that stores data 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 storage cost than a traditional cApp.

UPDATE # 4:

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.

---

As readers of my blog post entitled Flight Delay Insurance – Why Blockchain? would have sensed, I was never sold on the decentralization claim 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.

(https://twitter.com/s_ketharaman/status/1083642213589008384)

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.

I'm hopeful that, as long as legalities around ICO, token, and other thorny issues of blockchain are sorted out, Blockchain can be a game-changer in niche use cases like loyalty, automated title transfer, and metering, to name a few.

(https://twitter.com/s_ketharaman/status/1044866744748331008)

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 no longer that. In a recent edition of its e-newsletter, MIT Technology Review points out that, if a digital asset is decentralized, the US Securities and Exchange Commission doesn't 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 has legal implications now.