5 ms·

Anything where chain of custody is important is a great application in my humble opinion. Currently a huge problem in engineering is guaranteeing the legitimacy

Anything where chain of custody is important is a great application in my humble opinion. Currently a huge problem in engineering is guaranteeing the legitimacy of parts. Everything from electronics to commercial jet parts have knockoffs being made and passed off as legitimate. If you have unique QR codes for each part from the manufacturer you can use a blockchain to track chain of custody of the part. Beyond that you can make something unique digitally and hash it and someone can "own" that digital thing, instead of money it can be items in a game or art or anything really. A musician can make a song for a single person and sign it into a blockchain and you can prove who it was for. Lots of neat applications that haven't been created yet just like the internet when it was new.

qeternity 9y ago
A centralized database run by the manufacturer would accomplish the same thing. The number of trustless use cases, where blockchain really shines, is just not that large. Decentralization has a huge cost and most of the time it’s not worth the overhead.
- _trampeltier 9y ago
  In a centralized database it is allways possible to cheat. I think something like qualitiy data from a factory. Once you stored the data, there will be no way to change it later.
  - zaarn 9y ago
    Why would a vendor cheat in a database that contains only a list of legitimate parts from the vendor? It is in their interest to sell those parts and not have any knock-offs sold. 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)
  - iamben 9y ago
    I think the point the earlier posters are trying to make is that if a manufacturer is at a point where they need an immutable, decentralised quality record their problems are bigger than the record keeping. As someone buying parts you generally want to trust the manufacturer you're buying from, as someone making them, if you're at the point of making crap and faking records your days are probably numbered anyway. 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.
  - qeternity 9y ago
    As noted by other commenters, in most of the immutable data use cases that I have seen, these ignore the much greater business and operational risk placed in your counter-party. For instance, I place far more trust in an airline to get me from A to B alive and safe than I do for them to honor the fact that they issued me a ticket. We've already established a much higher level of trust based on profit (i.e. dangerous airlines lose customers) and thus a blockchain doesn't really add anything.
  - village-idiot 9y ago
    Since you have to, at some point, trust the manufacturer that they built what they said they built, there is no point in a "trustless" system. 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.
eridius 9y ago
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.
dcow 9y ago
Which of those examples needs to be distributed?

qeternity 9y ago

A centralized database run by the manufacturer would accomplish the same thing. The number of trustless use cases, where blockchain really shines, is just not that large. Decentralization has a huge cost and most of the time it’s not worth the overhead.

_trampeltier 9y ago
In a centralized database it is allways possible to cheat. I think something like qualitiy data from a factory. Once you stored the data, there will be no way to change it later.
- zaarn 9y ago
  Why would a vendor cheat in a database that contains only a list of legitimate parts from the vendor? It is in their interest to sell those parts and not have any knock-offs sold. 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)
- iamben 9y ago
  I think the point the earlier posters are trying to make is that if a manufacturer is at a point where they need an immutable, decentralised quality record their problems are bigger than the record keeping. As someone buying parts you generally want to trust the manufacturer you're buying from, as someone making them, if you're at the point of making crap and faking records your days are probably numbered anyway. 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.
- qeternity 9y ago
  As noted by other commenters, in most of the immutable data use cases that I have seen, these ignore the much greater business and operational risk placed in your counter-party. For instance, I place far more trust in an airline to get me from A to B alive and safe than I do for them to honor the fact that they issued me a ticket. We've already established a much higher level of trust based on profit (i.e. dangerous airlines lose customers) and thus a blockchain doesn't really add anything.
- village-idiot 9y ago
  Since you have to, at some point, trust the manufacturer that they built what they said they built, there is no point in a "trustless" system. 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.

eridius 9y ago

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.

dcow 9y ago

Which of those examples needs to be distributed?