I remember a project when I was consulting that was floated, a few years ago. It was a blockchain-backed ledger for tracking fuel charges across a truck fleet - effectively, when the truckies filled up with fuel, they'd record it in the ledger. It can't be modified or altered, nobody can defraud the company because it's an immutable record!, shouted the sales team.
I mean, the truckie could always put the wrong value in when he entered it.
Also if the company just created a simple web/mobile app for truckers to enter data that doesn't have edit and delete functionality it is immutable. Non programmers think immutability is inherent in a system and not something controlled by code. Even if I use a blockchain and cryptography to timestamp it, if I am the one controlling the node, who in the world can prevent me from going in and changing it and time stamping it again with the same old timestamp? And if I create the UI, what stops me from showing whatever I want on the UI?
It would still remove plausible deniability. The trucker would not be able to blame anyone else for entering the wrong data in the system.
Another advantage is that you immediately see if an entry in the ledger has been dropped due to a network or other technical error, which can be a problem if you’re running a complex state machine on the data. I once helped a company build an IoT product where that was a problem. I pitched the idea but got absolutely no traction. I think the mistake I made was not calling it a blockchain, but just said I wanted to include hashes in the messages, so it didn’t sound sexy enough. I don’t like blockchain hype either, I didn’t care about being public, distributed, having proof of work or consensus, I just wanted to know if and when a message had been dropped, which is apparently too much to ask.
Also I think the vendor of the actual device didn’t understand what message authentication was, so they wouldn’t have been able to make it happen on their end. Their idea of security was just encrypting the data, but making no effort to ensure who it came from. I also think they wanted to use DES, which had already been broken for a few years at that point.
The problem of paper trails being changed. When something goes wrong, if you can't trust your paper trail, you can't attribute fault with certainty.
Without an immutable shared database standard, it's difficult for processes like that to cross company lines. And supply chain is a fancy phrase for processes that cross many company lines.
It doesn't ensure that the data is correct, valid, hasn't been tampered with, or even entered.
A supply chain involves 3rd parties who have nothing to gain from this. If the issue is the middle man between A and C, blockchain isn't solving any problem. The distrust is with B, having a blockchained backed paper trail doesn't provide anything a database gives you right now.
You're asking for a single source of truth between A B and C. And saying you cannot trust A B or C, so you want blockchain to solve it, which needs to be created by someone, so you introduce D and now you have a central governing body who dictates everything for A B and C. Or you are A and you say 'hey B and C, you need to use this system we created cos we don't trust you!'.
Auditing is a core feature of most modern RDBMS systems.
Anyways the reason why it's immutable is that it's public so everyone knows every transaction. You can just have a normal db and maker it public. Blockchain is overkill in this case.
Also this is a much more niche problem than "supply chains"
I mean, the truckie could always put the wrong value in when he entered it.