< all Blog posts

Is traceability a good use-case for the blockchain? Using NIST.gov’s evaluation process

In our last cannabis and blockchain post, we mentioned traceability systems as a possible use-case for blockchain technology in our industry. We concluded that it’s at least an interesting idea, to bring these two emerging industries together and to demonstrate how the blockchain could help run a fundamental aspect of the cannabis industry. But is that really a good use-case, or are we simply injecting the blockchain into a system that doesn’t need it? How do we evaluate a software system to determine if blockchain is a good fit?

Thanks to a recent Hacker News discussion, I found just such an evaluation technique and I’d like to try applying it here. The process is a fairly simple flowchart designed by the National Institute of Standards and Technology (NIST) in a recent publication titled “Blockchain Technology Overview.” The flowchart is pictured below, and we’ll walk through each question.

NIST blockchain evaluation flowchart

“Do you need a shared, consistent data store?”

Yes. A state’s traceability system must be consistent and shared between many licensees and the state’s regulators.

“Does more than one entity need to contribute data?”

Yes. Each licensee needs to contribute their own transactions and inventory adjustments.

“Data records, once written, are never updated or deleted?”

Mostly yes. While mistakes can happen, they are generally fixed by adding another update, not by editing or deleting the original mistake.

“Sensitive identifiers WILL NOT be written to the data store?”

Depends, but probably WILL. A traceability system could be designed to not store sensitive information, but there is a lot of data currently stored in traceability systems that would be considered sensitive such as inventory and sales data for individual licensees, as well as medical patient data. This is the biggest immediate disqualification of blockchain for this traceability use-case, but we’ll keep moving through the flowchart.

“Are the entities with write access having a hard time deciding who should be in control of the data store?”

Mostly no. When Washington State had some headaches making their switch to a new traceability system, I did see frustrated licensees complaining that they didn’t want that company to be in control of the data store. But generally licensees don’t have a problem with the government contractor having this control – they just want more responsiveness to system issues. This is different than a use-case like Bitcoin, where the goal is to remove any centralized control. This answer again seems to disqualify traceability as an ideal blockchain use-case, but we’ll move forward.

“Do you want a tamperproof log of all writes to the data store?”

Yes. While we generally trust the government contractors to not tamper with the data, a tamper-proof system would certainly make the system more robust and reliable. If a licensee were in court for a violation and the traceability system was used as evidence, could they argue that the data was tampered with? Do the current systems have strong controls to prove there was no tampering? The blockchain would answer this question easily.

So, do we have a useful Blockchain use-case?

Probably not. Sensitive data will probably get written into the traceability database, and we generally aren’t having a hard time deciding who should be in charge of the data store except in times of frustration. Using NIST’s evaluation metric, we have to conclude that a Blockchain traceability system might be an interesting use case, but probably not a necessary or useful one.