[dangus]

I think a good resource to give you an idea of what blockchain can actually do comes from the "Blockchain use cases " and "Blockchain solutions" sections of IBM's Blockchain marketing page:

https://www.ibm.com/blockchain

This gives you an idea of some real world business problems that have been solved with the technology. Still, personally, I find the question of "when do I decide to consider using a blockchain as an implementation choice?" a difficult one to answer.

[bydlocoder]

You do know that IBM essentially shut down its blockchain division? https://finance.yahoo.com/news/ibm-blockchain-shell-former-s....

[arcticbull]

Azure Blockchain followed suit, shutting down in September 2021. [1]

[1] https://cointelegraph.com/news/microsoft-quietly-closing-dow...

[dangus]

No. I don’t really follow them closely, I just thought their marketing page was a good list of possible use cases.

The article did a good job explaining what general problem blockchain solves, but didn’t give me a very good idea of what problems one might try to solve beyond existing implementations.

[PeterCorless]

1. If you need to share all the data and the data distribution methods across multiple legal entities — there's no one 'owner' of the data like a company. If you are doing a blockchain implementation for an internal project... why? Why are you not just using a regular database like Postgres or MongoDB or Oracle or ScyllaDB? But if you are going to be sharing all this data across 50-100 companies, and no one themselves wants to "own" the project and host it, and if everyone wants to be participating as a near equal partner in a solution? Okay. Maybe distributed ledger is warranted.

2. If you need to be able to add more entities who want to participate in the distributed ledger. Or, conversely, drop out entities that are no longer participating, but everyone else still wants to preserve the history of their transactions. If you do deploy to a centrally-owned databsase, if the managing entity ever wants, for any reason, they can pull the plug on the whole operation. A distributed ledger ensures you can add people at any time — no one can lock you out from joining. And also it ensures that if you ever want to leave, the data and the work continue.

3. If you need strongly-consistent views of data, and you don't care about transactional limits. Most distributed ledger technologies are greatly bottlenecked in terms of transactions per second. And I mean some are limited to less than 10 transactions per second. Others can scale to thousands of operations per second. But many centrally-managed and even distributed databases can operate at millions of operations per second. So blockchain is not going to do anything like "eventual consistency." It just won't. And because of that, you'll have these strong throughput (ops per second) limits.

[Zanfa]

4. It can’t involve anything off the chain (physical assets or items) or your data integrity will require some sort of a centralized trusted oracle that defeats the trustless nature of the blockchain.

This basically means most of the examples in IBMs marketing (supply chain management, vaccine rollouts etc) don’t actually make any sense to do on blockchain vs using a regular database.

[arcticbull]

> Still, personally, I find the question of "when do I decide to consider using a blockchain as an implementation choice?" a difficult one to answer.

Luckily, there's a helpful guide available, if you hit Learn More on the first "most probably NO." [1] It's based on this paper. [2]

[1] http://doyouneedablockchain.com

[2] https://eprint.iacr.org/2017/375.pdf