5 ms·

How is this any better than the manufacturer just maintaining a database of legitimate parts (identified by QR codes) and then contacting the manufacturer when

How is this any better than the manufacturer just maintaining a database of legitimate parts (identified by QR codes) and then contacting the manufacturer when you want to know if a part is legitimate? About the only thing a blockchain would do is insulate you from the manufacturer's API going down. But even that can be solved by having the manufacturer simply send you a copy of the database periodically (and then contacting the manufacturer if your database copy doesn't have the part, in case it's newer than your database, although even that can be solved by having the manufacturer generate the codes in advance, so the database they give you can already contain the codes that will be used for parts manufactured over the next month). 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.

solotronics 9y ago
With a blockchain the end user could tag the part hash as being installed and you could see exactly who each supplier had the part at what time. A database could go offline and stop a part from begin installed into a jetliner but a blockchain would be always available. The manufacturer could track which parts the end user has in stock and installed and make production decisions easier. A consortium of manufacturers could use the same blockchain for all their parts. I am not claiming it's more efficient for all use cases just that there are some distributed trust applications that seem to make sense.
- eridius 9y ago
  The only interesting part here is the behavior when the manufacturer's API goes down, and that's solveable just by having the clients maintain a queue of their failed modifications and retry them later when the API goes back up again. And of course the manufacturer can even provide the software that does this to the client so the client doesn't have to do any work for it.
  - twic 9y ago
    This little subthread is a great example of a kind of fallacy that seems endemic amongst blockchain believers. "A blockchain solution X can solve problem P, therefore blockchain is useful". Without asking if there is a non-blockchain solution Y that can also solve P, and if so, what the relative merits of X and Y are. 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.
  - vsssk 9y ago
    Wait, so, if I used blockchain I wouldn't have to 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.
    - icebraining 9y ago
      maintain a queue of.. failed modifications and retry them later when the API goes back up again. 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.
  - langitbiru 9y ago
    The blockchain solution can gives more benefits more than "when the manufacturer's API goes down". 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.

solotronics 9y ago

With a blockchain the end user could tag the part hash as being installed and you could see exactly who each supplier had the part at what time. A database could go offline and stop a part from begin installed into a jetliner but a blockchain would be always available. The manufacturer could track which parts the end user has in stock and installed and make production decisions easier. A consortium of manufacturers could use the same blockchain for all their parts. I am not claiming it's more efficient for all use cases just that there are some distributed trust applications that seem to make sense.

eridius 9y ago
The only interesting part here is the behavior when the manufacturer's API goes down, and that's solveable just by having the clients maintain a queue of their failed modifications and retry them later when the API goes back up again. And of course the manufacturer can even provide the software that does this to the client so the client doesn't have to do any work for it.
- twic 9y ago
  This little subthread is a great example of a kind of fallacy that seems endemic amongst blockchain believers. "A blockchain solution X can solve problem P, therefore blockchain is useful". Without asking if there is a non-blockchain solution Y that can also solve P, and if so, what the relative merits of X and Y are. 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.
- vsssk 9y ago
  Wait, so, if I used blockchain I wouldn't have to 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.
  - icebraining 9y ago
    maintain a queue of.. failed modifications and retry them later when the API goes back up again. 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.
- langitbiru 9y ago
  The blockchain solution can gives more benefits more than "when the manufacturer's API goes down". 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.