Hacker News new | comments | ask | show | jobs | submit login
NIST: Blockchain Technology Overview [pdf] (nist.gov)
190 points by infodocket 3 months ago | hide | past | web | favorite | 33 comments



I found the blockchain use case flow chart here to be excellent. pg 42


Haha, that's brutal. By which I mean brutally accurate. I would be happy to show that to anyone considering a blockchain.


You think conditions that satisfy that flow chart don't exist?


In my opinion, very little current business practices fall under a positive answer to this:

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

Because by definition, if the business practice exists in the first place it is because they already found a solution to collaborate.

I'm almost tempted to add a snarky: "for further information, please refer to this article: https://en.wikipedia.org/wiki/Law"


I understand why you might think that that isn't an issue, but it absolutely is. Think about stagnant systems that persist for seemingly incomprehensible reasons. SWIFT payments, paper stock settlement, do you know how bond trading works? Paper. Someone has to physically sign it over.

Do you know why these legacy methods persist? They persist not because the people involved don't know there's a better way. They persist because nobody can agree on who should control the new way.

This is exactly the problem that blockchains solve. This point is subtle, but it is extremely important, and it absolutely needs to be taken seriously.

I should point out, that Git solves exactly the same problem, by the way. You don't want a centralized entity hosting your project? Great, use git. Git, by the way, is a blockchain.


Git is not a secure blockchain. It's quite easy to rewrite history in git to change the true order of events (after all, that's the whole purpose of rebase). A true blockchain has to be protected by cryptographic signing protocols; git is not.


A) What is your point?

B) Git is perfectly secure if you don't accept pushes.


My point is that it cannot solve the problems a blockchain can. You could not build a digital currency on git.


Cryptocurrencies are just git + proof of work. Git, on its own, is a blockchain. Adding proof of work to a blockchain solves the timestamping problem, which allows you to use that blockchain as a currency (i.e. prevent double spends). Many times that property is useful (more than just in currencies, e.g. trading stocks), but not always, and it is not an essential property of a 'blockchain'.


No. That's the beautiful thing about it. It doesn't try to tell you there are no good use cases, just that there are very few and you almost certainly don't have one.


Well, except that there are actually quite a few. Git (distributed version control), for instance. Currencies, for another. Asset trading of any kind. Supply chain management and authenticity validation. Maybe you think those things are 'few', but they are quite critical.


"Few" is quite enough to establish that most people should use something else, regardless of how crucial the rest may be. Speaking of "enough", enough with the "git is a blockchain" thing. It's a chain of blocks, but it's not a "blockchain" in the sense that term is actually used, and everyone knows it. You're not helping your case with that.


Oh, so a thing can have all of the properties of a blockchain, but because it doesn't suit your narrative, it is not one? That doesn't seem like much of an argument to me.

Tell me, which of the conditions of the flow chart does git not satisfy? And better yet, which technical property of a blockchain does git lack that disqualifies it?

You seem to be trying to define blockchain as "a thing without a use case", and then when presented with a use case say "see look it has a use case! it's not a blockchain!".


git is not what people call "blockchain", only half of it. The distributed consensus part is not there. Maybe that's what it's both efficient and popular?


Git absolutely has distributed consensus. That's what merges are. That's the sense in which git is decentralized.

What git does not have is distributed timestamping, which is necessary for a currency, but not version control. And which is why PoW et al were introduced for cryptocurrencies. However, that is not a fundamental property of a blockchain, though it is useful for some (but not all) of the applications of blockchains.


Except, ya know, trustless currency. :p


Sadly it leaves out distributed hash tables, which is a commonly ignored solution to a lot of the "problems" that bring people to blockchain.


p53 in pdf :)


I think we should stop wasting public funds on blockchain and here is why.

Records are important in the public sector, but what’s more important is how we handle changes. This is because changes to a record in one system, might affect changes in a range of other systems, and what most governments are building to handle this is advanced observer patterns, where a central messaging bus keeps tracks of alterations and informs subscribers.

Like if you get sick with depression, a case worker will register this and a range of things will happen where different departments and systems are notified to build a case flow for your way back to work. Other systems will ensure you get your welfare and so on.

Or if you trade property, a ton of systems needs to be notified about it.

Blockchain suck at this because they are extremely inefficient.

Now the records are important too, but today, bi temporal data is playing an ever increasing part in the public sector.

What this does is keep every change on record. Allowing case workers to look up something, and get a timeline representing every state of your record.

Blockchains are surprisingly bad at this as well. It keeps the records, but trolling through them and finding the relevant ones is just incredibly bad compared to traditional databases.

Decentralisation is probably never going to happen. Especially because the public sector will never do a proof of work concept since the environmental cost would be political suicide. If you’re doing a voting blockchain, then the public sector will never relinquish control, and if you don’t do that, then you might as well not use blockchain.

So I think you can actually go through the use case chart on page 53 of the pdf and still find a lot of areas where you should say no.

I’m danish and I think half of our muniplacities as well as our government and all of our banks (banking IT is extremely similar to public sector IT except its narrow focus/range) have done proof-of-concepts on blockchain for the past decade. No one has found a good use case that couldn’t have been run without blockchain yet. I sometimes wonder how much money we’ve wasted trying to find a usecase, and it’s a lot, and I can’t tell you why we’ve done that.

I mean, if only we’ve spend all those resources on something useful.


Are there not more than one blockchain? Shouldn't it be blockchains?

"Blockchain(s) suck at this because they are extremely inefficient."


Probably, English is my third language so I’m kind of bad at it. You should see how it looks without the autocorrect. :p


Incredible for a third language. Motivational, really.


You must not like Git very much then.


I do, and we use that sort of hash trees for a lot of bi temporal data keeping.

I wouldn’t call it blockchain though.


In what sense do you believe that it is not a blockchain? Because I would say that Git is an extremely compelling use case that satisfies all the criteria in that flow chart.


Well for one you can rewrite git history, and there is no independent verification of what you change.


Blockchains get their history rewritten all the time too, it's call a re-organisation and occurs naturally whenever two blocks are found close enough together that the network splits over which one came first. You can also get longer rewrites of history when there's a bug or an explicit decision to fork the chain.

The idea that blockchains are 'tamperproof' or can't be changed isn't really true. At most you can say that participants can become aware of such changes. But that's also true of git.

That said, there are a lot of good uses for the tech as long as "the tech" is understood widely. If you look at the enterprise blockchain space they're moving away from classical proof of work type systems, they all use BFT algorithms instead, and some of them don't have blocks at all (like Corda). They're more git-like and they provide most of the advantages but without the disadvantages; which can indeed be very useful for many types of business.


I haven't read this paper yet, but I'm a fan of many things published by NIST. If you're a software engineer I'd suggest browsing their website [0]. They have a lot of great high quality content freely available.

They run the US stations for (almost? not 100% sure) everything related to time-keeping [1] [2].

In particular I've found many of their publications on identity management and authN / authZ very helpful in helping me understand the needs of the enterprise. They have some great primers on role-based access control [3] with examples of some of the different kinds of edge-cases one runs into and how they can be solved. It's far too common to read an explanation that just tells you: you can do whatever you want! When you're getting started in a domain it can be incredibly helpful to know how others solved the same problems.

Here's the publication link [4] on the NIST website. I was going to say that I thought it'd be better to link there so people could read the abstract without having to download the full PDF... But I just checked and the website and all its resources weight in over 1MB while the PDF is around 0.77MB. The state we're in is quite unfortunate; I remember their older website being quite nice and fast.

Abstract:

Blockchains are tamper evident and tamper resistant digital ledgers implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority (i.e., a bank, company, or government). At their basic level, they enable a community of users to record transactions in a shared ledger within that community, such that under normal operation of the blockchain network no transaction can be changed once published. This document provides a high-level technical overview of blockchain technology. It discusses its application to cryptocurrency in depth, but also shows its broader applications. The purpose is to help readers understand how blockchain technology works, so that they can be applied to technology problems.

[0] https://www.nist.gov/

[1] https://www.nist.gov/pml/time-and-frequency-division/time-se...

[2] https://www.time.gov/aboutB.html

[3] https://csrc.nist.gov/projects/role-based-access-control

[4] https://www.nist.gov/publications/blockchain-technology-over...


NIST is wonderful, government at its best. Thank you for the links.


Great! I'm glad to see blockchain is actually being recognized by a part of the U.S department of commerce. I think in the next few years we could see a superior blockchain based currency dominant global markets.


It's quite a jump from "recognize its existence" to "blockchain rules the world economy", especially considering problems discussed in Chapter 7.


You should probably look at page 53 before you interpret this as praise.


You should probably actually understand the flowchart before interpreting it as criticism.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: