Heck, you don't really even need a database for this at all, come to think of it. Just have the QR code contain a signed copy of the part identifier. You can validate that the signature matches the manufacturer's public key and that will be just as good as asking the manufacturer if it's valid.

Also, now that I think about this, this whole scheme (including using a blockchain) has the fatal flaw wherein a knockoff can just copy the QR code from a valid part. There's nothing stopping anyone from reusing the QR codes, and the knockoff will appear just as legitimate as the original.

Given that a blockchain is just a distributed database with a distributed certification mechanism, you can generally immediately construct a couple of non-blockchain solutions by first removing distributed certification, then distribution of the database itself. You can then quickly see the eigenmerits of those kinds of distribution for the problem at hand. I have yet to see an example where they are positive.

So there are 3 actors in supply chain: manufacturers, retailers, and consumers. In your solution (centralized database and API), you rely on the goodwill of the manufacturers which is fine (I guess) in most cases. But retailers and consumers have good reason sometimes not to trust the manufacturers. Vice versa.

Okay, let's consider this case: the manufacturer produces milk packaged in a bottle. So they put QR code in the milk, and put some information in their database. Let's say they put the production date into this database.

QR code: Abbbccc Information: produced on January 5th 2018

They send the milk to the warehouse A. Warehouse A keeps the milk for a night before sending to the retailers. But alas, there is a storm preventing the warehouse sending the milk to the retailers. So 1 week later, it delivers the milk to the retailers. Warehouse A informs the manufacturer about the incident. But let's say this milk only has 10 days before it hits expiry date after the production. Manufacturer decides to lie to the retailers. They updates the database.

QR code: Abbbccc Information: produced on January 11th 2018

In blockchain, this corruption can be prevented.

Say the manufacturer instead just has an RSS feed on their site, where they publish that information (digitally signed, of course) as the milk is produced. The retailers just have to keep a local copy of that feed, and so they can detect any later tampering.

</sarcasm>

That said, this does bring to mind one genuinely useful aspect to the blockchain I forgot about, and that's the fact that Keybase uses the bitcoin blockchain (IIRC) to periodically record the Merkle tree roots that they use to verify their own information. The only reason to do this is as proof that they're not tampering with the Keybase history that they publish, and so fundamentally this is just the same thing as digital notarizing that I did mention before (except in this case it doesn't matter whether the courts recognize it as being valid). And you could still accomplish this without a blockchain simply by having a neutral third party agree to keep a record of the merkle tree roots, but this is one of the few cases where the 'trustless' aspect of the blockchain actually is useful.

Though of course even with a 'trustless' blockchain you still have to trust the chain itself. With Bitcoin, you can assume nobody's managed to execute a 51% attack against the chain (at least, for the time being; AIUI with the way things are going it looks like the Chinese government might be able to do it by exerting pressure on all the Chinese miners), but if you're running your own chain, how do you make mining the chain popular enough to prevent attacks?

In fact, to my mind, the only real benefit of Bitcoin at this point is the fact that it's so popular it's hard to attack (well, except by the Chinese government).

I'm not actually a Bitcoin/blockchain hater; I can't avoid having a soft spot for any tech that makes me feel like I'm living in a cyberpunk world :) What I dislike is the mania. Bitcoin is a cool experiment, not a production-ready solution to anything.

maintain a queue of.. failed modifications and retry them later when the API goes back up again.

neither would I have to

provide the software that does this to the client so the client doesn't have to do any work for it.

You're literally describing a benefit of blockchain. Its right under your nose.

Your blockchain client still has to have a queue of transactions to be submitted, as the Internet is not magically reliable.

You're literally describing a benefit of blockchain. Its right under your nose.

It is a benefit of the blockchain, in the same way that transporting people is a benefit of a dump truck. That doesn't mean it's appropriate for that job.

There are many, many tools for storing and pushing messages to remote servers. The blockchain clients can do it, but it's absurd to use them unless you need the rest of the blockchain stuff. Even an email server (MTA) would be a better option.

The same goes for quality data, mostly because even if the vendor provides it, basically any industry partner will absolutely insist on doing sample tests on the quality anyway. That also doesn't remove the factor where the quality results are cheated before being put on the blockchain.

A blockchain is not very useful when

A) all participants are trusted or

B) there is no incentive to cheat or

C) if there is incentive to cheat there are already countermeasures available that are more useful (ie, doing samples and having a contract that specifies damage payments in case quality does not match)

Second, you have yet to actually provide any motivation for end clients to spend money or hardware on a manufacturer's blockchain. Chances are the manufacturer would have to maintain all the miners, which is silly.

Third, the manufacturer in this case would have all of the signing keys, since they're the only ones that can make parts. This also damages the selling point of the blockchain.

So no, this does not work.

If you somehow managed to persuade an industry to get on board, for the most part, those with nothing to hide are the ones a decentralised quality database is the least useful for - anyone trying to hide anything (manufacturer / buyer) is going to avoid taking part or cut corners anyway.