Doomed to be subsumed by whichever Chain-of-Custody/Certification-of-Origin blockchain project wins out in the long run. And there are lots of them -- this is an obvious and compelling use of the technology. It's just a case of waiting to see which solution dominates, but I'm pretty certain it WON'T be a proprietary or vendor-owned blockchain since that violates the very thing a blockchain solution brings to the table -- trustless verification.
I'm not sure; it doesn't seem obvious that the certification chains of unrelated products should be on the same blockchain, and it doesn't seem obvious that users of this system will want to pay the high energy prices of proof-of-waste.
Seems to me that once you've solved the problem, applying it across a variety of unrelated products is an easy thing to do, with the advantage that your solution is already proven, has gained some traction in another sector and is not something new and untried. It's one of those things where the first one to win is likely to win big (unless they fuck it up along the way somehow.)
Not sure how your comment on PoW applies, though (despite agreeing with you.) Plenty of the solutions in developments are using PoS/other/hybrid consensus mechanisms.
I wonder how one may prove that a thing originates from some specific place? I mean, you have to have some kind of trusted by all parties external observer who will assure that fact. Am I wrong here?
I've seen many claims that the blockchain can be used to provide traceability for various goods but I don't get it.
For one thing this isn't trustless, the blockchain doesn't know what a diamond is so if a person entering a new diamond to the blockchain "database" decides to lie there's no way to prevent it "trustlessly". How do you prevent the same diamond to be entered twice in the chain? How do you prevent somebody from entering a diamond that doesn't exist in the chain? How do you make sure that some physical diamond you have in your hands matches an entry in the blockchain (and one only)? The ledger is immutable but diamonds aren't, what if a diamond is recut and the blockchain entry is not updated to match? What if I decide to "launder" some blood diamond by adding a transaction on the blockchain saying that it was destroyed, followed by a brand new clean entry pretending that I've just mined a new one?
In the end you'd have to trust some sort of authority to put the diamonds on the chain honestly.
So if you have decided to trust some authority, what do you need the blockchain for? Just have the De Beers cartel digitally sign a certificate for each diamond like an HTTPS certificate authority and bundle it with the stone. Exactly the same trust model and you don't have the overhead of the blockchain.
Is there a use case that I'm missing or is it just yet an other occurrence of "let's say we do blockchain stuff and people will throw money at us"?
You are correct. Humans will be the weakest link in this security link, specially at the origin. Bitcoin etc solve this by using PoW. But here there can be issue if there is a malicious first entry
That said, a case might be made for a traceable and immutable book which shows the movement of each diamond. But that might run into privacy issues. This can be solved by using a private blockchain but then again it goes back to trusting someone who has the blockchain with them.
I agree with you but I want to point out that "a traceable and immutable book" is perfectly achievable without blockchain. Just have De Beers (or the authority of your choice) publish their signed "immutable" ledger publicly at regular intervals. Anybody can mirror it (like the "nodes" of bitcoin mirror the blockchain). If the authority decides to cheat and rewrite history (for instance to change the origin of a diamond) any of the 3rd party mirrors can detect the conflict and blow the whistle.
Interesting point, thanks for sharing. But, anyway:
What incentives do those mirroring nodes have to store regular data blobs and process requests from clients?
Who will decide the privilege to be such a 'mirroring node'. The origin can run several such 'mirroring nodes' and rewrite history on all (some of) them: how would you know who is giving you the truth in case of conflicting information?
I bet if you solve those questions, you will be simulating a blockchain system. Do you agree?
While not completely familiar with the technology that DeBeer's is using, I can comment on the general advantages of blockchain for Chain-of-custody.
I am more familiar with pharmaceutical and food safety applications and so will comment on those.
Firstly, with chain-of-custody one is tracking something external to the blockchain, so there is no getting around the fact that one needs to place some trust in the entities writing to the blockchain.
The better way to think about it is that the blockchain allows you to trust "who" wrote to it and "what" they wrote, not whether what they wrote was an accurate reflection of the real world or not. (The real-virtual mapping problem)
In the pharma industry for example you have hundreds of manufacturers and thousands of wholesalers and tens of thousands of pharmacies, thousands of carriers, thousands of re-packers, thousands of customs brokers, hundreds of freight forwarders and 3PLs etc.
Furthermore, unlike Diamonds, it is not a simple linear flow of serialized items. Many items are actually lot-tracked and not serial-tracked. So, now you have the notion of splitting of lots and blending and combining of lots. Additionally items will go back and forth between distributors.
Additionally, you have IOT readings along the entire provenance history like temperature, humidity, location etc.
When an entity receives a serial or lot tracked item they can trace its provenance on the blockchain and decide whether and to what degree they want to trust whether what the previous entities wrote to the blockchain needed to be second guessed.
Often when receiving, entities will perform some sort of QA. The degree of QA will be dictated by who, what, when and where the item went through in its entire journey.
If they have high trust in the entities in the chain of custody they may only do partial check (eg. check for no broken seals), but if they don't trust the entities in the chain they may do a full assay of a sample or they may take the middle ground and do a quick spectrophotometry analysis. With any of these results they can write their certification to the blockchain so that subsequent entities may not have to re-certify if they trust this intermediate entity.
So, one way to think about this is that chain-of-custody is not all or nothing, but rather based on degrees of trust. Also every participant views the situation differently based on whom they trust.
Now back to the original question of whether this could be done with a central database instead of blockchain. The answer is "of course", but now even the who and the what is potentially suspect IN ADDITION to the virtual-physical mapping problem.
Blockchain-based chain-of-custody solutions allows one to design a system focused only on mitigating the real-virtual mapping problem.
>Now back to the original question of whether this could be done with a central database instead of blockchain. The answer is "of course", but now even the who and the what is potentially suspect IN ADDITION to the virtual-physical mapping problem.
I don't really understand that. The "who" can be authenticated using digital signatures (say, a PGP signature for instance, or a certificate signed by the authority in change). This is exactly the way a blockchain would work, making a transaction means signing it with your private key. As long as your private key remains private nobody can impersonate you (but that's not revolutionary blockchain technology, that's goold old seventies asymmetric crypto technology).
As for the "what" I'm not sure what you mean by that. If somebody (the "who") digitally signs a message or transaction and its contents (the "what") gets modified somewhere along the way then the signature will fail to validate. On the other hand if I get a signed message by entity A saying something that turns out to be false then it's proof that A lied, was compromised or made a mistake.
Yes, you are right. But if you imagine the full provenance of a lot or serial tracked item having hundreds of "messages", it is true they could all be digitally signed by the entities submitting them which would prove "who" sent the "messages".
However, keep in mind that all these messages need to be correlated and subject to business logic and validations. For example, the business logic might dictate that one cannot record a temperature reading to the blockchain if the chain-of-custody does not show you as the current possessor of the item.
Alternatively, the business logic may say that you cannot blend a non-blendable lot.
There are thousands of business rules that need to be enforced along the way.
With the (say) PGP approach, you would need to ADDITIONALLY trust that the entity applied these business rules correctly. Also in this approach, there is no single version of the truth. So, every entity maintains its own version of the truth leading to huge synchronization problems in addition to trust problems.
Authentication of a write operation is not the only problem a blockchain system solves. Using a public blockchain, for example, you are assured that:
0) all writes are authenticated
1) all the data written will be accessible to anyone
Now contrast it with a centralized solution where admit can just restrict access to some data. Yes, all writes are authenticated, but who cares if you cant access them?
2) The history of all writes is also reliably preserved and accessible to anyone.
3) In case of smart contracts, the business logic is visible to you upfront. You can study the contract and decide if it is fair to participate. You can study the history of that contract also.
4) All "redundant" nodes have proper incentive to participate in the activity. They gain value just by validating and processing your transactions.
My point is that this is just not achievable using traditional DBMS: the original premises ("trust model" and incentive model) of those systems are very different.
So let's say we etch a QR code into each diamond which is only visible with a microscope. This is not unfeasible. In fact "Polar Bear" diamonds carried an etching of a polar bear. [1]
So once you have the etching of a QR code then it makes sense for a blockchain, because then it makes determining the provenance for a diamond easier. And you could track stolen diamonds much, much easier.
Though, I would be disappointed if DeBeer's only allowed it for their diamonds only.
1) Do diamonds have unique digital fingerprints? How do I know if the diamond I see in front of me corresponds to the record the dealer shows me on the blockchain?
2) What happens when people (inevitably) put bad information in the permanent digital record? Does anybody have the authority to correct it?
"Before a stone like this can be digitised, pricey or not, it needs a unique identifier – a fingerprint – that allows it to be tracked on Everledger’s platform as it changes hands.
This is calculated from 40 data points related to each stone – alongside the Four C's. Any diamond over 0.16 carats will also have a serial number inscribed on its girdle during the grading process.
While a criminal could reshape a stone to distort its 'digital fingerprint', Kemp explained that diamonds are not, in fact, the sum of their parts. The cutting process results in a lot of wastage, so any attempt to alter a diamond, or split it into two, will drastically reduce its value."
As for your second question, it depends on what kind of platform the diamond industry builds on. If the diamonds are tracked using a smart contract on the public Ethereum chain, there may be special functions in the contract that allow certain entities to edit data in the contract. The problem with this is that consumers have to trust that the companies use this write access honestly. A partial solution might be to only allow certain data in the smart contract to be edited IF at least X number of companies in the consortium agrees to it. Still requires trust, but less of it.
If they're building their own blockchain to track the diamonds, and consensus is simply maintained by a small group of entities in the industry, then it's trivial to edit the data. But of course, if this is the case, then it begs the question of why a blockchain is even needed. Just use a shared database.
>But of course, if this is the case, then it begs the
>question of why a blockchain is even needed. Just use a
>shared database.
Two issues regarding your second observation.
1) A change that requires a consensus among some non-tiny group of participants is not trivial thing to accomplish in practice. You will have to wait before every one from a group of N (say, 20) representatives will agree with your change.
2) Why a blockchain is needed? Because no other "shared database" provides the same trust model which is "everyone trusts no one". Every other database "security model" in existence assumes that every admin trusts every other admin. If it is not so, then things quickly become complicated and impractical.
Good points. From a consumer's perspective, I do hope that they would eventually choose to build on a public blockchain. The fact that consensus is provided by miners worldwide (or stakers in PoS chains) instead of a couple of diamond-related companies means that there is one less thing for me trust.
There's something very poetic about this, as the similarities of diamond cartels [1] and cryptocurrencies [2] effectively granting a small amount of people the control the majority of supplies of artificially constrained assets both of which have vastly inflated prices relative to production costs.
26 comments
[ 3.6 ms ] story [ 60.5 ms ] threadNot sure how your comment on PoW applies, though (despite agreeing with you.) Plenty of the solutions in developments are using PoS/other/hybrid consensus mechanisms.
For one thing this isn't trustless, the blockchain doesn't know what a diamond is so if a person entering a new diamond to the blockchain "database" decides to lie there's no way to prevent it "trustlessly". How do you prevent the same diamond to be entered twice in the chain? How do you prevent somebody from entering a diamond that doesn't exist in the chain? How do you make sure that some physical diamond you have in your hands matches an entry in the blockchain (and one only)? The ledger is immutable but diamonds aren't, what if a diamond is recut and the blockchain entry is not updated to match? What if I decide to "launder" some blood diamond by adding a transaction on the blockchain saying that it was destroyed, followed by a brand new clean entry pretending that I've just mined a new one?
In the end you'd have to trust some sort of authority to put the diamonds on the chain honestly.
So if you have decided to trust some authority, what do you need the blockchain for? Just have the De Beers cartel digitally sign a certificate for each diamond like an HTTPS certificate authority and bundle it with the stone. Exactly the same trust model and you don't have the overhead of the blockchain.
Is there a use case that I'm missing or is it just yet an other occurrence of "let's say we do blockchain stuff and people will throw money at us"?
That said, a case might be made for a traceable and immutable book which shows the movement of each diamond. But that might run into privacy issues. This can be solved by using a private blockchain but then again it goes back to trusting someone who has the blockchain with them.
What incentives do those mirroring nodes have to store regular data blobs and process requests from clients?
Who will decide the privilege to be such a 'mirroring node'. The origin can run several such 'mirroring nodes' and rewrite history on all (some of) them: how would you know who is giving you the truth in case of conflicting information?
I bet if you solve those questions, you will be simulating a blockchain system. Do you agree?
marketing bullshit
> is it just yet an other occurrence of "let's say we do blockchain stuff and people will throw money at us"?
Probably. Has their share price gone up yet? :-)
I am more familiar with pharmaceutical and food safety applications and so will comment on those.
Firstly, with chain-of-custody one is tracking something external to the blockchain, so there is no getting around the fact that one needs to place some trust in the entities writing to the blockchain.
The better way to think about it is that the blockchain allows you to trust "who" wrote to it and "what" they wrote, not whether what they wrote was an accurate reflection of the real world or not. (The real-virtual mapping problem)
In the pharma industry for example you have hundreds of manufacturers and thousands of wholesalers and tens of thousands of pharmacies, thousands of carriers, thousands of re-packers, thousands of customs brokers, hundreds of freight forwarders and 3PLs etc.
Furthermore, unlike Diamonds, it is not a simple linear flow of serialized items. Many items are actually lot-tracked and not serial-tracked. So, now you have the notion of splitting of lots and blending and combining of lots. Additionally items will go back and forth between distributors.
Additionally, you have IOT readings along the entire provenance history like temperature, humidity, location etc.
When an entity receives a serial or lot tracked item they can trace its provenance on the blockchain and decide whether and to what degree they want to trust whether what the previous entities wrote to the blockchain needed to be second guessed.
Often when receiving, entities will perform some sort of QA. The degree of QA will be dictated by who, what, when and where the item went through in its entire journey.
If they have high trust in the entities in the chain of custody they may only do partial check (eg. check for no broken seals), but if they don't trust the entities in the chain they may do a full assay of a sample or they may take the middle ground and do a quick spectrophotometry analysis. With any of these results they can write their certification to the blockchain so that subsequent entities may not have to re-certify if they trust this intermediate entity.
So, one way to think about this is that chain-of-custody is not all or nothing, but rather based on degrees of trust. Also every participant views the situation differently based on whom they trust.
Now back to the original question of whether this could be done with a central database instead of blockchain. The answer is "of course", but now even the who and the what is potentially suspect IN ADDITION to the virtual-physical mapping problem.
Blockchain-based chain-of-custody solutions allows one to design a system focused only on mitigating the real-virtual mapping problem.
I don't really understand that. The "who" can be authenticated using digital signatures (say, a PGP signature for instance, or a certificate signed by the authority in change). This is exactly the way a blockchain would work, making a transaction means signing it with your private key. As long as your private key remains private nobody can impersonate you (but that's not revolutionary blockchain technology, that's goold old seventies asymmetric crypto technology).
As for the "what" I'm not sure what you mean by that. If somebody (the "who") digitally signs a message or transaction and its contents (the "what") gets modified somewhere along the way then the signature will fail to validate. On the other hand if I get a signed message by entity A saying something that turns out to be false then it's proof that A lied, was compromised or made a mistake.
However, keep in mind that all these messages need to be correlated and subject to business logic and validations. For example, the business logic might dictate that one cannot record a temperature reading to the blockchain if the chain-of-custody does not show you as the current possessor of the item.
Alternatively, the business logic may say that you cannot blend a non-blendable lot.
There are thousands of business rules that need to be enforced along the way.
With the (say) PGP approach, you would need to ADDITIONALLY trust that the entity applied these business rules correctly. Also in this approach, there is no single version of the truth. So, every entity maintains its own version of the truth leading to huge synchronization problems in addition to trust problems.
My point is that this is just not achievable using traditional DBMS: the original premises ("trust model" and incentive model) of those systems are very different.
Please correct me if I am wrong somewhere.
So once you have the etching of a QR code then it makes sense for a blockchain, because then it makes determining the provenance for a diamond easier. And you could track stolen diamonds much, much easier.
Though, I would be disappointed if DeBeer's only allowed it for their diamonds only.
[1] https://www.theglobeandmail.com/news/national/diamonds-mined...
It's a shame as diamonds aren't really worth that much, just a monopoly.
1) Do diamonds have unique digital fingerprints? How do I know if the diamond I see in front of me corresponds to the record the dealer shows me on the blockchain?
2) What happens when people (inevitably) put bad information in the permanent digital record? Does anybody have the authority to correct it?
"Before a stone like this can be digitised, pricey or not, it needs a unique identifier – a fingerprint – that allows it to be tracked on Everledger’s platform as it changes hands.
This is calculated from 40 data points related to each stone – alongside the Four C's. Any diamond over 0.16 carats will also have a serial number inscribed on its girdle during the grading process.
While a criminal could reshape a stone to distort its 'digital fingerprint', Kemp explained that diamonds are not, in fact, the sum of their parts. The cutting process results in a lot of wastage, so any attempt to alter a diamond, or split it into two, will drastically reduce its value."
If they're building their own blockchain to track the diamonds, and consensus is simply maintained by a small group of entities in the industry, then it's trivial to edit the data. But of course, if this is the case, then it begs the question of why a blockchain is even needed. Just use a shared database.
Two issues regarding your second observation.
1) A change that requires a consensus among some non-tiny group of participants is not trivial thing to accomplish in practice. You will have to wait before every one from a group of N (say, 20) representatives will agree with your change.
2) Why a blockchain is needed? Because no other "shared database" provides the same trust model which is "everyone trusts no one". Every other database "security model" in existence assumes that every admin trusts every other admin. If it is not so, then things quickly become complicated and impractical.
[1] https://en.wikipedia.org/wiki/De_Beers#Diamond_monopoly
[2] http://www.businessinsider.com/bitcoin-inequality-2014-1