Slashdot Mirror
'You Do Not Need Blockchain: Eight Popular Use Cases And Why They Do Not Work' (smartdec.net)
Ivan Ivanitskiy: People are resorting to blockchain for all kinds of reasons these days. Ever since I started doing smart contract security audits in mid-2017, I've seen it all. A special category of cases is 'blockchain use' that seems logical and beneficial, but actually contains a problem that then spreads from one startup to another. I am going to give some examples of such problems and ineffective solutions so that you (developer/customer/investor) know what to do when somebody offers you to use blockchain this way.
1. Supply chain management
Let's say you ordered some goods, and a carrier guarantees to maintain certain transportation conditions, such as keeping your goods cold. A proposed solution is to install a sensor in a truck that will monitor fridge temperature and regularly transmit the data to the blockchain. This way, you can make sure that the promised conditions are met along the entire route.
The problem here is not blockchain, but rather sensor, related. Being part of the physical world, the sensor is easy to fool. For example, a malicious carrier might only cool down a small fridge inside the truck in which they put the sensor, while leaving the goods in the non-refrigerated section of the truck to save costs.
1. Supply chain management
Let's say you ordered some goods, and a carrier guarantees to maintain certain transportation conditions, such as keeping your goods cold. A proposed solution is to install a sensor in a truck that will monitor fridge temperature and regularly transmit the data to the blockchain. This way, you can make sure that the promised conditions are met along the entire route.
The problem here is not blockchain, but rather sensor, related. Being part of the physical world, the sensor is easy to fool. For example, a malicious carrier might only cool down a small fridge inside the truck in which they put the sensor, while leaving the goods in the non-refrigerated section of the truck to save costs.
However, this quote from the article highly entertained me:
Oddly enough, even non-working cases may be useful. Say a corporation uses a long-outdated process/system. Instead of opting for a normal and obvious solution, management decides to invest in hype (blockchain/big data/AI/IoT) to gain a lead....If you are offered the chance to use blockchain, make sure it is actually blockchain. However, even if it is not, it could still be a sensible offer.
I am sure IBM right now is selling people "blockchain" technology that doesn't have any blockchain at all, just like they sell Watson technology without and Watson. It's a brand.
"First they came for the slanderers and i said nothing."
Hadoop has been a fantastic example of this. Everyone and their goldfish think they need hadoop because they have SO MUCH DATA! Does your data measure in petabytes? No? Then you don't have as much data as you think you do.
The funny thing is when they have all this NoSQL or highly scaleable stuff and they are still having trouble. I saw a company recently that was having trouble getting more than a hundred open orders at a time, considering all kinds of exotic solutions. I wanted to be thorough and eliminate all potential problems, so I asked, "Do you have indexes on your tables?" They said, "Well, we recently started added in them." Alright then. Let me blow your mind with the mysql "Explain" command.
"First they came for the slanderers and i said nothing."
I saw the same thing just recently. An application and I was working with used a traditional SQL RDBMS, and there was a screen that listed all open orders that was slower than syrup. The offshore developers wanted to move the tables used by that screen to MongoDB for a resolution. They had managed to convince upper-management that this was the only solution. They sure had egg on their face after I rewrote the stored procedures and added a few indexes.
If you post as Anonymous Coward, don't expect a reply.
NIST has a good document on blockchain, see Section 8:
* Do you need a shared, consistent data store? If yes:
* Does more than one entity need to contribute data? If yes:
* Data records, once written, are never updated or deleted? If yes:
* Sensitive identifiers WILL NOT be written to the data store? If yes (i.e., public data only)
* Are the entities with write access having a hard time deciding who should be in control of the data store? If yes:
* Do you want a tamperproof log of all writes to the data store? If yes
* You may have a useful Blockhain use case
* https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
That's a lot of "if yes" conditions to meet.