If by “a blockchain” (or “a distributed ledger”) you mean “a distributed data store using cryptographic functions and blocks of data chained together” then it basically means “software technology” and indeed pretty much everything can be digitized with software. It also means that people have been developing “blockchains / DL” for decades. It’s a fallacy. It’s like saying any mobile application is a form of “Uberization”. Saying that all blockchains are “immutable and decentralized” because the Bitcoin system is, is like saying that all vehicles are safe, fast and clean because the Tesla Model 3 is.
In reality, blockchains were specifically conceived as “a consensus system allowing to exchange scarce digital units of value between unidentified people, without using a unique or a small group of authorities”.
The provenance of goods (supply chain) or the certification of diplomas is obviously not a blockchain problem because:
a) There is no unit of value. Let’s state the obvious: no accounting ledger, no blockchain!
b) Nobody is trying to double-spend anything. It’s not like you want random people to buy and sell certificates of authenticity.
c) There is no need for a consensus. Universities are not fighting each other to certify the master that John Doe did at Harvard
d) Users are identified: registered firms contributing to the supply chain, students, etc.
e) There are natural authorities: the product owner owns the IP and is liable, the US Department of Agriculture, organic/non-GMO accredited certifying agents, Universities, etc.
Let’s examine the two main requirements of supply chains / provenance use cases:
1. The secure storage of digital proofs
2. The validity of the proofs themselves
1. It is entirely possible to build a centralized secure storage of digital proofs
* Append-only persistent databases can be implemented centrally
– This old paper ac.els-cdn.com/00220000899003…
– This more recent PWC report
* Transparency is easy to achieve: simply expose the data on the internet
* Resiliency is achieved through backups, disaster recovery, etc.
* Digital signatures & verifiable timestamps were widely used long BB (Before Bitcoin). This is Merkle’s patent from 1979.
To make this work, you only need to trust the admin of the PKI, who can mess up with the keys. For this purpose, an effective governance and effective controls are built to protect the PKI and Certificate Authorities (CA). In the hypothetical 0.001% cases (please share if you know any) when there is NO WAY an effective governance & effective controls can be implemented, you still don’t need a blockchain data structure to decentralize the control of the master keys: use Shamir secret sharing.
I have seen ZERO case with a convincing cost/benefit analysis demonstrating when and how a blockchain/DL is preferable to a conventional distributed database to store proofs. By default a blockchain/DL is more complex & expensive (more network traffic, more CPU, more storage, etc), so you have to make your case!
2. A blockchain cannot guarantee the validity of the proofs themselves
This is well documented. In short: a blockchain does not know if your meat is beef or horse meat. You have to trust humans to certify the link between the digital and the physical worlds. But humans cheat & lie, that’s the problem. Blockchains can do nothing to prevent counterfeits, forgeries or simply human errors.
The only way it would work is if you could engrave a unique and persistent ID to a product, and if the ID could not be removed or copied along the transformation chain (it must contain unique properties of the product). You would need a verifiable autonomous machine to do the engraving and linking to the system. Then it’s verifiable. In French we call that “usine a gaz”, meaning an unnecessarily complex solution that provides no benefits.
Some firms are developing interesting techniques (see for instance dustidentity.com) but this problem has absolutely nothing to do with blockchains.
To conclude, here are two large recent provenance systems that don’t use a blockchain to track products, because you don’t need a blockchain for that:
* The European Medicines Verification System EMVS
* NSA Software to Mitigate Supply Chain Management Risk
3 thoughts on “Supply chain is obviously not a blockchain use case”
I see a few issue in your raisonning: you are talking of supply chain, but you use diploma to support your claim. The two uses cases are different.
For instance, “nobody is trying to double spend anything”: that’s wrong especially in the supply chain…. Counterfeit meat is an exemple of double spending , like reusing a valid certificate of origin on something else
“there is no unit of value exchanged” : wrong again, in all business process, including supply chain, unit of value are exchanged (goods is the most obvious one)
“The blockchain does not garantee the validity of the proofs”: I totally agree, that’s why in a blockchain use case, the weak point are the entry points, and that’s usually where you still need trusted third party to provide “trusted proofs”. Once entered in the blockchain, this can not be altered
The unique ID does not needs to be complex, it can be quite simple as long as :
– only trusted third party can produce it (and it’s usually the originator of the item, so simple)
– you can link id with ownership -> it will be for instance hard for somebody to copy existing car piece even if there is just a sticker on it, unless this one (the seller) is copying piece. In that case, it will be quite easy to find who in the supply chain is trying to duplicate items.
Hi… These blogs offer a lot of information about blockchain development.Your blog is incredible. I am delighted with it. Thank you for sharing this wonderful post.