
NIST's answer to “Do you need a blockchain?” - alanfranz
https://imgur.com/a/RlUj9Ed
======
Derek_MK
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"

~~~
calibas
I think the days of "mad investor money" just because you added blockchain to
something may be over. The hysteria over blockchain went hand-in-hand with
last year's cryptocurrency bubble, I wouldn't be surprised if smart investors
are avoiding it now.

~~~
cabaalis
I also wonder how many projects exist now where the blockchain they decided to
build their implementation upon will become technical debt.

Also, dig your username, lol.

~~~
CydeWeys
Definitely the vast majority of them.

Bitcoin and Namecoin are the only really compelling use cases I've ever seen.
Even Ethereum kind of falters because there's not much you can really
accomplish with a purely digital contract.

~~~
greggyb
This might be seen as picking a nit, but I think the distinction is important.

Ethereum falters not because you can't do much with a purely digital contract,
but because people typically want the guarantees of a digital contract _except
when they don 't_. There is so much value (if only from inertia), of being
able to fall back onto negotiation, or in a more negative circumstance
litigation, around an existing contract.

The digital contract is too rigid for how contracts are typically executed in
the real world.

~~~
posterboy
I read the parent implying the opposite. The cases where the eth contracts are
secure, because they only rely on actions captured in and only in the network,
are very few.

------
zellyn
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.

~~~
pythonaut_16
Doesn't that somewhat depend on how you define a blockchain? Blockchain
doesn't inherently require proof of work/stake/etc, just a chain where each
block contains a hash of the previous block(s). Proof of work/stake just
happens to be a popular implementation detail because of cryptocurrencies.

~~~
beaconstudios
what you're describing is a Merkle tree. Blockchains are essentially Merkle
trees with a distributed consensus algorithm. Take away the consensus
algorithm and you're back to Merkle trees.

~~~
zellyn
[https://twitter.com/whitequark/status/946886702932557824](https://twitter.com/whitequark/status/946886702932557824)

[https://twitter.com/hikari_no_yume/status/933791331146784768](https://twitter.com/hikari_no_yume/status/933791331146784768)

More seriously, some people apparently consider git a blockchain:
[https://medium.com/@shemnon/is-a-git-repository-a-
blockchain...](https://medium.com/@shemnon/is-a-git-repository-a-
blockchain-35cb1cd2c491)

~~~
pdpi
Git histories absolutely are something in the blockchain family of data
structures, yes, but they’re not a blockchain proper: the defining
chacteristic of such data structures is that they use hashes instead of
pointers as references to elements. Merkle trees and blockchains are analogous
to trees and singly linked lists, respectively, while git histories are DAGs.

Where things got murky was that the cryptocurrency crowd started to talk about
the blockchain that backs Bitcoin in terms where the consensus layer was left
implicit (our own Linux vs GNU/Linux story if you want to see it that way),
then people less knowledgeable about cryptography started pouring in, they
learned a bunch of new terminology, and along the way missed the nuance about
the consensus layer being left implicit, so in their minds (and the world at
large, eventually) blockchain means the combined data structure and consensus
layer — It’s fairly obvious that git doesn’t meet the requirements for this
definition of “blockchain”.

------
ballenf
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.

Blockchain doesn't inherently do any data translation or normalization.

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.

~~~
jrochkind1
> one big misconception is that blockchain will magically solve the
> interoperability issue where multiple parties have data in disparate
> formats.

That reminds me so hard of RDF/"linked data", which was (and is still in some
sectors) popular for same motivation I think.

Data interoperability is a real problem, with real pain, which is why people
get so excited about tech they think will solve it. But no magic technology is
going to solve it, it's a human problem. (At least I can see _why_ people
(wrongly) thought RDF would; no idea how they arrived at that misconception of
blockchain).

~~~
vec
> (At least I can see _why_ people (wrongly) thought RDF would; no idea how
> they arrived at that misconception of blockchain)

There was briefly the bad idea that "NoSQL means we don't have to care about
our schemas anymore" bridging the other two bad ideas.

------
nradov
The actual NIST report is here.

[https://csrc.nist.gov/publications/detail/nistir/8202/final](https://csrc.nist.gov/publications/detail/nistir/8202/final)

------
simias
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".

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.

~~~
tim333
I could see a situation where several rival pineapple growers supply several
rival pineapple retailers where they are not sure who should control the data
store but where there would be an advantage to having an auditable record. If
they lie, the recipient of the iffy pineapples could go hassle the supplier.

Not sure about the virtues of signed public database/logs vs blockchains.

------
3chelon
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.

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.

------
commandlinefan
I was honestly expecting a picture of the word "No".

~~~
joshschreuder
[http://doyouneedablockchain.com/](http://doyouneedablockchain.com/)

------
m-i-l
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).

~~~
JoshuaDavid
Or scalable and decentralized systems that aren't secure (e.g. SMTP) :)

~~~
m-i-l
Yes, and as per your example this combination also doesn't need blockchain.
The only combination that actually needs blockchain is decentralised and
secure.

------
garysahota93
The blockchain "revolution" is very similar to AI, bots, IoT, Web 2.0, etc
etc.

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.

------
zitterbewegung
Seems to be very similar to this diagram from the hyperledger edX course.

[https://www.jsemeraro.com/wp-
content/uploads/2017/12/Blockch...](https://www.jsemeraro.com/wp-
content/uploads/2017/12/Blockchain-Decision-Path-edX.jpg)

~~~
elliekelly
This[1] is one of the sources provided in the NIST Report[2] appendix of
references.

[1] [http://doyouneedablockchain.com/](http://doyouneedablockchain.com/) [2]
[https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf)

~~~
greyhair
Nice to see at least one comment from someone that has actually read the
document....

------
berbec
Could have been simplified to "no"

~~~
pythonaut_16
Except this is an actually helpful diagram that points you towards other
solutions depending on what benefits you think a blockchain might give you,
instead of an (unhelpful) outright dismissal.

------
kawfey
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.

[0]: [http://www.arrl.org/logbook-of-the-world](http://www.arrl.org/logbook-
of-the-world)

~~~
jrockway
LotW is just bad engineering to solve a problem that doesn't exist. I have
never used it and never will.

Ultimately a QSO is something between two people. If both people believe they
made a QSO, they made a QSO. If you want to have a contest over who can make
the most QSOs, you need a judge to define what their definition of a QSO is.
LotW is not a judge, but rather a bunch of random antique network protocols
with cargo-cult cryptography thrown in to make it as difficult as possible to
use. But you can still easily lie about having made a QSO. So it solves
nothing.

For those that aren't hams, enjoy:
[http://www.arrl.org/files/file/LoTW%20Instructions/Quick%20S...](http://www.arrl.org/files/file/LoTW%20Instructions/Quick%20Start/TQSL%202_0.pdf)

Also, a "QSO" is basically radio contact between two parties. Most people
agree a QSO has been made when the remote party understands your callsign, you
understand theirs, and that you have verified the understanding. (Some people
are more liberal or more conservative, however.)

~~~
mprev
I love the idea of sending data over ham radio but, outside some kind of
disaster or simply making hams happy, is there a practical use?

~~~
jrockway
Is there a practical use? Not really. Satellites and fibers are more reliable
than hoping the ionosphere is in the right configuration for the path that you
want to send messages on.

It is nice to know that you can communicate with the other side of the world
using no infrastructure, but it's unlikely that it will ever be necessary.

Airplanes on oceanic routes use HF radios, which is the same idea as ham
radio. I am not sure why they don't use satellites. I guess it's cheaper than
buying satellites.

~~~
ric2b
Might be useful during wartime, since it's likely that lots of infrastructure
will be taken down.

------
calibas
So if you want a "tamper-proof", auditable, decentralized data store, go with
block chain.

~~~
dfox
Notice that the flow chart does not mention decentralized. The
"decentralization" in cryptocurrencies come from whatever mining/proof-of-
something mechanism build on top and has nothing to do with blockchain itself.

~~~
calibas
It mentions decentralization, but in a rather smart-ass way:

"Are the entities with write access having a hard time deciding who should be
in control of the data store."

------
jacquesm
Could we please have another one for AI?

And while we're at it another for serverless architectures?

~~~
jedberg

         Are you writing all the code?
         |                  |
         Yes                No
         |                  |
         Use serverless     Use containers

------
snissn
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.

------
CydeWeys
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.

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.

~~~
sigstoat
> Some of these miss the mark, e.g. depending on what you're doing with PII
> storing hashes or symmetric encryptions would work fine.

granted that "depending on what you're doing" is a big caveat, but:

i feel like there's a difference between encrypting my PII with an ephemeral
session key, then sending it in some packets across the internet that are
unlikely to be captured, and encrypting my PII with some not-very ephemeral
key, then writing it to the disks of thousands or millions of people with a
big "this is PII" sign on top of it.

~~~
CydeWeys
There wouldn't be a "this is PII" sign on top of it. By its nature you don't
know what encrypted data is unless you can decrypt it, and there's many other
things that people would be encrypting and putting on the blockchain that
aren't PII (probably the vast majority of them wouldn't be). And that's only
for the symmetric case anyway; in the hash case it's non-reversible and the
majority of the blockchain data is already hashes anyway.

Also, your "ephemeral encrypted packets" are probably logged to disk in
multiple three-letter agency databases.

------
M2Ys4U
Do you want to help ruin the planet by wasting a tremendous amount of power?
If yes, consider Blockchain

~~~
jtonz
You are thinking of cryptomining, specifically ones that use proof-of-work
blockchains.

------
greyhair
Funny how almost everyone seems to be discussing the diagram and not actually
reading the NIST paper first hand.

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.

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.

[https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf)

------
lwansbrough
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.)

------
philip1209
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.

~~~
root_axis
Blockchains are pointless for "enterprise security" because "enterprise"
already implies a trusted authority.

~~~
Karunamon
Being in an enterprise doesn't mean you have ultimate trust of every single
individual with write access. There's a reason many orgs operate under a two-
person rule for access to some data, have change controls, and so forth.

~~~
root_axis
That's irrelevant. The point is that the enterprise is a centralized authority
so it can trivially codify its business rules into a centralized system;
nothing is gained by using a blockchain. Tracking, audits, and tamper
resistance is already possible without a blockchain.

~~~
Karunamon
Only thing I took issue with is the overbroad statement "because "enterprise"
already implies a trusted authority"

It does not necessarily.

~~~
root_axis
No. It necessarily does. The enterprise is the final authority regarding
whether or not the system is behaving correctly, not a distributed consensus.

------
r32a_
Definition of blockchain is fluid because a blockchain is a combination of
many technologies.

------
nwsm
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.

[0]: {Shared and Consistent, More than One Contributor, Distributed Control,
Tamperproof Log}

------
platz
sometimes you don't really want a blockchain, you actually want a "Distributed
Ledger".

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.

The Difference Between Blockchains & Distributed Ledger Technology
[https://towardsdatascience.com/the-difference-between-
blockc...](https://towardsdatascience.com/the-difference-between-blockchains-
distributed-ledger-technology-42715a0fa92)

------
sklivvz1971
The last step should be "You should use git"

------
SilasX
Is there a source document that can be linked instead?

~~~
niftich
PDF page 53 of the document with canonical URI of [1], resolved by the doi.org
resolver [2] to a pdf with a NIST URL [3].

[1] doi:10.6028/NIST.IR.8202

[2]
[https://doi.org/10.6028/NIST.IR.8202](https://doi.org/10.6028/NIST.IR.8202)

[3]
[https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf)

------
jesusthatsgreat
You don't need a blockchain until corruption and lack of transparency forces a
need for one in order to re-build trust.

~~~
sekai
Wouldn't it make sense have some sort of solution before it happens? Like
Venezuela.

------
mthom
It is almost as though, prior to blockchain, nobody had conceived the idea of
a distributed spreadsheet.

~~~
zeroxfe
The idea definitely existed -- it's just that no one had cracked how to keep
it correct and consistent until Bitcoin demonstrated how proof-of-work could
be used as a practical consensus algorithm.

(Prior implementations of digital currencies always relied on some kind of
centralized mechanism to prevent double-spending.)

------
paraditedc
pdf of the document:
[https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf](https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf)

~~~
SilasX
I think the mods should switch the link to this one.

~~~
alanfranzoni
It's linked at the bottom of the imgur link. And scrolling down to page 42 is
not exactly quick :-)

------
known
NIST nailed it :)

------
ucaetano
TL;DR: No.

~~~
erikpukinskis
TL;DR: Probably not but maybe

------
seibelj
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.

~~~
SilasX
If you don't care about keeping a voter's vote secret, the problem becomes a
lot easier to begin with, and permits a lot of non-blockchain solutions. Like
publishing votes in the newspaper.

~~~
seibelj
But you can keep them secret and selectively reveal them to auditors, etc.
Just like they do now, when they reveal them during a recount.

~~~
SilasX
Current audits don't see information that connects a ballot to a voter.

