Decentralized Database over DLT

When the frenzy of Blockchain or Distributed Ledger Technology (DLT) was at its peak, someone made the following statement to cool down the expectation:

A Blockchain is just a glorified distributed and decentralized database.

The merit of the statement depends on the definition of "Decentralized Database". Such concept is related to replicated database. I would propose the following definitions:

• A centralized (replicated) database is a cluster of database replicas that is "stop-fail failure" tolerant.
• A decentralized (replicated) database is a cluster of database replicas that is "Byzantine fault" tolerant (BFT).

"Stop-fail" failure simply abstracts process crashes and is a benign failure, and the common database replication technologies for HA deals with such failures (for example: the MySQL HA strategy deployed at Github). The "Byzantine fault" though abstracts all forms of erroneous or even malicious behaviors of participating processes in a distributed system. In a decentralized environment, where replicas are controlled by different administrators without full trust between them, DLT provides BFT consensus for the replication cluster.

A DLT protocol (such as the protocol of how nodes behave and interact with each other in the Bitcoin, Ethereal or a Hyper Ledger network) provides the foundation for implementing a "Decentralized Database". But how is such abstraction useful in real life? I proposed and prototyped the abstraction in the context of enterprise applications as an incubation project at Microsoft in 2018. The following document is the specification of Decentralized Entities and Decentralized Transactions for Cross-enterprises Business Applications.