Don't forget the first step "Do you not really care about the technology and just want to write a webapp that gets mad investor money?" and an arrow that goes straight to "Yes"
You can do merkle-tree-signing and other clever things with cryptography to provide auditability without needing any kind of distributed consensus via proof of work/stake/etc. so I think the flowchart could have a couple more "No" branches.
In talking to a few companies who thought they wanted a blockchain, one big misconception is that blockchain will magically solve the interoperability issue where multiple parties have data in disparate formats.<p>Blockchain doesn't inherently do any data translation or normalization.<p>It's interesting to me how resilient this misconception is. I have come to the conclusion that it's just wishful thinking for a magic bullet for an age-old difficult problem.
The actual NIST report is here.<p><a href="https://csrc.nist.gov/publications/detail/nistir/8202/final" rel="nofollow">https://csrc.nist.gov/publications/detail/nistir/8202/final</a>
I think the key point that crypto-enthusiasts often miss here is "Are the entities with write access having a hard time deciding who should be in control of the data store". For many purported use-cases for blockchains (things having to do with traceability of goods for instance) the answer to this question is most likely "no".<p>For instance if you want to trace a shipment of pineapples there must be some entity somewhere who's tasked with making sure that the goods are up to code (otherwise anybody could just lie on the blockchain). This entity is clearly "in control of the data store". Of course you may want to be able to publicly audit that entity's records to detect any wrongdoings or suspicious activity, but that doesn't require a blockchain at all, simply having a signed public database/log (that anybody could archive) would do the trick nicely for instance.
I remember trying to explain this to a bank I worked for a few years ago. The trouble is, they're all so hyped up by the buzzwords they don't listen.<p>And before I knew it they'd hired a self-styled "blockchain consultant" at god knows what daily rate. I realised I was fighting a losing battle. Probably should have reinvented myself there and then as a blockchain consultant.
Also note the "blockchain trilemma": at the moment you can have decentralised and secure systems that don't scale (e.g. Bitcoin), or you can have scalable and secure systems which aren't decentralised (e.g. all the "private permissioned blockchain" solutions which don't actually need to use a blockchain).
The blockchain "revolution" is very similar to AI, bots, IoT, Web 2.0, etc etc.<p>These were all mainstream "fads" that died down over time. As I've said before, many of these technologies are revolutionary and extremely useful - but only in their respective domain. Calling any of them, blockchain included, the end-all-be-all is foolish. There are some legitimate use cases for which this will apply greatly. But it's only a matter of time before another technology goes viral only for folks to realize it's intended use cases and then simmer down to a focuses, purpose-driven tech.
Seems to be very similar to this diagram from the hyperledger edX course.<p><a href="https://www.jsemeraro.com/wp-content/uploads/2017/12/Blockchain-Decision-Path-edX.jpg" rel="nofollow">https://www.jsemeraro.com/wp-content/uploads/2017/12/Blockch...</a>
One perfect use case is amateur radio cloud logging. Logbook of the World[0] is the defacto standard, which implements cryptographic signing, but the database is centralized, and it's consistently broken, lagging, and needs frequent updates and downtime, and due to this it probably costs a lot of money to the American Radio Relay League (ARRL) and her members. Blockchain is the perfect solution IMO.<p>[0]: <a href="http://www.arrl.org/logbook-of-the-world" rel="nofollow">http://www.arrl.org/logbook-of-the-world</a>
The concept of "You" is sort of interesting. If "You" want to build something that isn't centrally owned by "You" then you should use a blockchain. Satoshi Nakamoto doesn't "own" bitcoin anymore than anyone else does. Same with most other blockchain projects. The problems come when "You" want to have your cake and eat it too.
Some of these miss the mark, e.g. depending on what you're doing with PII storing hashes or symmetric encryptions would work fine. Similarly, updates can be accomplished by writing new entries, which is how Bitcoin works; you read all blocks ever and steadily build up a (local) database of all the unspent transactions, and update those as new blocks come in. Namecoin works similarly but for DNS entries. It's no different than replaying a transaction log in a standard DB (once) to reconstruct the current state.<p>Where >99% of blockchain proposals fall down, though, is that they don't actually need the "anyone can commit" property. Businesses sure as hell wouldn't allow random strangers to commit to their internal blockchain, so they don't really need one at all. They would only allow some small number of vetted, authenticated external parties to do so, in which case normal account mechanisms work fine.
Funny how almost everyone seems to be discussing the diagram and not actually reading the NIST paper first hand.<p>And then nitpicking over the very definition of what block chain is. But then saying 'bitcoin' 'ethereum' 'git' and 'merkle tree' over and over and over.<p>Given the title of the thread, and the availability of the actual text, I suggest everyone take a quick read first, then come on back. It is only 50 pages.<p><a href="https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf" rel="nofollow">https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf</a>
It seems to me that a better solution for auditing in situations where you don’t need a distributed ledger is using event sourcing. Blockchains are just a data structure after all. You wouldn’t say “just use a b-tree.” Event sourcing databases solve most of the problems blockchain companies seem to think they have. (And the other problems they have probably won’t be solved with Blockchain anyway.)
I'm surprised somebody hasn't yet made an "audit log as a service". The Reddit comment editing is one place that shows why companies cannot be trusted. But, for enterprise security, you also want a log that cannot be tampered with.
I don't have a specific use case in mind but it seems that some subset of these, for example [0], would necessitate, or at least be aptly solved with a blockchain.<p>[0]: {Shared and Consistent, More than One Contributor, Distributed Control, Tamperproof Log}
sometimes you don't really want a blockchain, you actually want a "Distributed Ledger".<p>It's similar in that a DLC also requires consensus.
It's different in that a DLC need not be a "chain of blocks". i.e. a linked-list as it's core data structure.<p>The Difference Between Blockchains & Distributed Ledger Technology
<a href="https://towardsdatascience.com/the-difference-between-blockchains-distributed-ledger-technology-42715a0fa92" rel="nofollow">https://towardsdatascience.com/the-difference-between-blockc...</a>
pdf of the document: <a href="https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf" rel="nofollow">https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf</a>
I think blockchain is staring us in the face as a solution to the collapse of trust in institutions. For example, if all votes were stored on a permissioned blockchain, audits would be trivial. If we layered it on top of our existing (bad) election technologies and did a post-election comparison of accuracy, I bet it would be far more accurate.