NIST's answer to “Do you need a blockchain?”
imgur.com
imgur.com
Also, dig your username, lol.
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.
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.
"Smart contracts" aren't necessarily analagous to actual contracts. They can also be programmed with configurability.
That said, I've also seen a bunch of "X, but with blockchain! Can we have money now?" startups looking for funding.
I was chatting to a blockchain enthusiast friend about building something along those lines myself for recording which ingredients came from where but the whole blockchain bit seems a bit tacked on to be trendy. I mean the more obvious way to record the data would be in a regular database but I guess you could write it to a chain as well so people could be sure it hadn't been altered. Dunno.
Watching the video at the end of the techcrunch article there's an IBM guy saying a problem is people record what's gone where with all sorts of incompatible systems - paper, local computers etc which makes it slow to figure which farm did it when you get food poisoning. I guess saying they have to write to data to an open blockchain rather than a Walmart database might be an easier sell?
There doesn't seem much too much hysteria going on there. He's hoping to be a leader in STOs which are a less scammy more regulated version of ICOs.
(Yes, private permissioned blockchains aren't necessarily p2p, but I'd argue that they need to use byzantine consensus too -- otherwise there's no reason not to just use a managed database instead.)
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...
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”.
Proof-of-work is code that passes tests and consensus is "Linus said 'ok'".
That said, if you don't have something like that, then most the rest of the bubbles don't make a whole lot of sense, either. When there's one central authority, they have the ability to unilaterally rewrite history, so you've also lost any features that flow from that not being possible, such as strong auditability.
Git seems like a decent litmus test. Is git, rebase and all, a blockchain technology, or merely a blockchain-like technology?
An example would be that I, as the central entity, know which public keys/key pairs I want to trust, and the proof of work is the owner of said key signing a given block with it. So as the central authority I can't unilaterally rewrite history, but I can unilaterally decide whether the chain is valid.
E.g. Alice wants to deliver a package to Dan by means of Bob and Carlos as couriers. So Alice signs the initial block using her public key and gives the package+signed block to Bob, who signs and gives to Carlos, who signs and gives the package to Dan. Dan can independently verify his trust in Alice, Bob, and Carlos's public keys and then be sure that the package was passed along in the manner recorded in the blockchain.
If trusting Alice, Bob and Carlos's public keys is equivalent to trusting them, then I don't really need a blockchain to verify that they did what they said they did.
If it's not, then I don't trust the blockchain as a record of what happened, because there's no chain of trust between what they wrote in the blockchain and what they actually did.
The reason why this sort of thing works with cryptocurrency is because, with cryptocurrency, the blockchain is reality. If the blockchain says I have 1BTC, I have it. If it doesn't, I don't.
As soon as you try to apply it to something like supply chain management, though, that falls apart. The map is not the territory. So you have to add a whole bunch more stuff to the system to try and ensure that what's been recorded is accurate. Not entirely unlike how, in the story of the stone soup, people had to add a whole bunch more stuff besides the stone to the pot in order to make sure the soup was tasty and nutritious.
I guess you could just store it in a database and store the hashes and signatures as columns but again, that seems more like implementing a blockchain strategy using a traditional RDBMS.
*After your edit: It seems like the blockchain is still useful in this case as a series of signed statements where it can be (generally) verified that each signature was made by a certain entity at a certain point in the chain.
Why would I need to do such a thing? What, in practical terms, does it get me?
The value of the system is that Bob cannot modify what Alice has said and signed. So the only place where Bob could lie is in his own block. Additionally, once Carlos signs his block, Bob and Alice can no longer change their statement either, so we're partly relying on Carlos to verify that he receives the package in the condition described by Bob's block.
One vulnerability I see is Carlos could just cut out Bob and fork the chain with his own block coming right after Alice. To counter that you could have each sender sign off on who they entrusted the package to (i.e. Alice signs her block/creates a block saying she gave the package to Bob).
So essentially the idea is to set up a system of untrusted participants whose identities can be verified/trusted. Bob might have an incentive to lie about who he received the package from or what the condition of the was package when he received it, but he doesn't have much incentive to let other people sign messages using his key.
I'm not sure as a system whether there is actual value or benefits here over other simpler solutions, it's just a fun thought experiment I've been doing to try and figure out scenarios where blockchains could provide real benefits over other systems.
If you can centralize the records management, then you don't have a problem deciding who should own the record store. At that point, good old-fashioned authentication will solve your problem.
If you can't centralize records management, then things get trickier. But I think the trickiest part would still be to come up with a non-contrived logistics scenario where there isn't an obvious custodian you can put in charge of a centralized record.
A tamperproof log with certain commodity hardware might be easier than guaranteeing secure network access to every participant in the chain.
One example I've seen in the wild is Walmart investing in blockchain for food safety. This is me in a sense trying to reverse engineer that thought process/system to figure out what benefits it might bring.
Looks like the system I'm thinking of is roughly a Proof of Authority system (https://en.wikipedia.org/wiki/Proof-of-authority). Your point about blockchain being unnecessary here is one of the points brought up in the Wikipedia article under Comparisons.
How about ZFS filesystem?
One implemtation I would like to see is a consensus algorithm applied to a multiplayer p2p game to prevent hacking.
Another implementation could be for digital assets like textures/skins, 3d models, and animations. This could take something like steam workshop and make it distributed.
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.
It was there with Big Data ("Who cares? Just throw it in a data lake!").
It was there with NoSQL ("Who cares? Just throw it in a document store!")
It was there with XML ("XML is just one format, right?")
It was there with COM/CORBA/AppleScript/etc ("The vendor can make their own data readable!")
I wouldn't be surprised if, millennia ago, there were organizations trying to figure out how fluted spear heads might solve their communication woes.
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).
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.
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.
Not sure about the virtues of signed public database/logs vs blockchains.
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.
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.
https://www.jsemeraro.com/wp-content/uploads/2017/12/Blockch...
[1] http://doyouneedablockchain.com/ [2] https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
This is why the phrase Bitcoin not Blockchain has been floating around.
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...
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.)
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.
Currently it's a centralized database that anyone can input data into. In this use case you'd simply decentralize the DB.
Blockchains are needed in cryptocurrencies to prevent the double spend problem. There's no double spend problem in logging radio contacts. The incentives to attack are much less too, because there's no value to steal.
"Are the entities with write access having a hard time deciding who should be in control of the data store."
Yes.
Decentralized just means someone else can own it too.
Seems this is an exercise in how loosely we can define blockchain. In my opinion all that's being achieved is confusing blockchains, as defined by their creator, with merkle trees.
If tomorrow Linus rewrites even a part of history of [0], every single one of Debian, Canonical, Red Hat, Amazon, Gentoo, Google, AOSP and my-friend-who-always-builds-mainline are going to notice. They are all going to continue to have the choice to fork their own; only this time, better motivated. Hell, if Linus is sensible in such a scenario, he will abandon his 'history-rewritten' fork and clone one of these guys' and carry on, just so everyone can stay on the same fork with the least effort.
Yes, rewriting history would be a fork. Git is not a VCS where a remote can rewrite local branches. Only the local user can make Git do so. If someone decides to follow Linus's history-rewritten fork, they will have to voluntarily do so; and even if they don't, they can always carry the original fork on among themselves, paying no heed to Linus [1]. Does this sound similar to how forks work in Bitcoin and Ethereum?
----
0: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
1: This is because Linus is the owner of only one repo: [0]. Upon cloning a repo, the cloner becomes the owner of the clone. Ownership does not transfer. A cloner is free to go their separate way with their clone, as they are free to continue to copy changes dilligently from the source, and everything in between. Git does not concern itself with reputation or authority.
In the case of something like a cryptocurrency, letting everyone create their own version of a ledger and get to decide which one is "correct", would be a complete and total failure of the system.
In my opinion, that should be part of what differentiates a merkle tree based VCS from a blockchain. The point of a blockchain is a singular, decentralized, "immutable" data store. Unlike git, version control is not what everything revolves around, version control is there so we can be sure it's a singular, decentralized, "immutable" data store.
I just don't see the point in defining blockchains so vaguely that even git counts. In practice, these are different systems that deserve different terminology.
And with cryptocurrencies, everyone can go fork it and create their own ledger. That not many do it is unrelated to the datastructure.
> In the case of something like a cryptocurrency, letting everyone create their own version of a ledger and get to decide which one is "correct", would be a complete and total failure of the system.
Yes, as a system.
> In my opinion, that should be part of what differentiates a merkle tree based VCS from a blockchain.
A "merkle tree based VCS" is a system. A cryptocurrency is a system. A blockchain is just a datastructure.
> The point of a blockchain is a singular, decentralized, "immutable" data store.
Which git is.
> Unlike git, version control is not what everything revolves around
In git, version control is not what everything revolves around. Git was designed for version control, and a merkle-tree of objects and dirtrees and metadata and commits was chosen to implement it on, which is what everything revolves around.
Just like how Bitcoin was designed for payment, and a blockchain of transactions was chosen to implement it on.
> I just don't see the point in defining blockchains so vaguely that even git counts.
This sounds a bit like you're trying to come up with a definition of "blockchain" with an express purpose of excluding git from it.
> In practice, these are different systems [emphasis mine] that deserve different terminology.
And this, is the heart of our disagreement. You're comparing the systems git and cryptocurrencies, only you call the latter "blockchains". I'm comparing datastructures, and I distinguish between the terms "cryptocurrency" (which I consider a system) and "blockchain" (which I consider a datastructure).
I think you're just rebelling against the common definition of a blockchain as a distributed ledger, though I don't understand what's to be gained from that. Seems the community is rather split about this...
Does it matter? What was the first linked-list?
> I think you're just rebelling against
I'm not "rebelling", I'm asserting.
> the common definition of a blockchain as a distributed ledger
That's a common application, not a definition; like blockchains and VCSes are common applications of merkle-trees, but not definition.
> though I don't understand what's to be gained from that
Nothing more that what's to be gained from asserting a linked-list is a list made of elements linking to each other. A blockchain is a chain made of blocks that depend on other blocks up the chain.
The initial 1955 implementation within the Information Processing Language.
Come on, the history of computer science isn't exact esoteric knowledge so if you know so much about how blockchain is "supposed" to be defined it should be easy to find where they came from.
And yes, every hash tree is a chain of blocks, nobody's arguing against that. The argument is whether or not blockchain should be defined so vaguely that it means the exact same thing as "hash tree", especially considering that blockchain is already in widespread use under a different definition.
What you're doing is arguing semantics and asserting that mekle tree, hash tree, and blockchain so all mean the exact same thing. That's just going to confuse people even more...
This would, however, make their node incompatible with everyone else's, in exactly the same way that rewriting the history of a Git repository makes that repository not able to automatically pull from or push to any other non-rewritten repos.
You seem to be thinking of 'git' as a thing which gets stored on GitHub, but it's entirely possible to run a repository with no central copy, based only on consensus. (I've actually done this--in an area without an internet connection, we spent a day coding and passing around copies on flash drives and merging until everyone had the same code. I don't recommend doing this on a regular basis, but there's no technical differences preventing it.)
I think the confusion is people are equating merkle trees with blockchains.
And while we're at it another for serverless architectures?
Are you writing all the code?
| |
Yes No
| |
Use serverless Use containersWhere >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.
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.
Also, your "ephemeral encrypted packets" are probably logged to disk in multiple three-letter agency databases.
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.
It does not necessarily.
[0]: {Shared and Consistent, More than One Contributor, Distributed Control, Tamperproof Log}
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...
[1] doi:10.6028/NIST.IR.8202
[2] https://doi.org/10.6028/NIST.IR.8202
[3] https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
(Prior implementations of digital currencies always relied on some kind of centralized mechanism to prevent double-spending.)
In a world where people genuinely believe Hillary Clinton received millions of votes from illegal immigrants, I don't see how a specific (and complex) technological implementation is going to solve those trust issues.
tl;dr
Blockchain systems do not magically make the data in them accurate or the people entering the data trustworthy, they merely enable you to audit whether it has been tampered with. A person who sprayed pesticides on a mango can still enter onto a blockchain system that the mangoes were organic. A corrupt government can create a blockchain system to count the votes and just allocate an extra million addresses to their cronies. An investment fund whose charter is written in software can still misallocate funds.
...
Before blockchain can even get involved, you need to trust that voter registration is done fairly, that ballots are given only to eligible voters, that the votes are made anonymously rather than bought or intimidated, that the vote displayed by the balloting system is the same as the vote recorded, and that no extra votes are given to the political cronies to cast. Blockchain makes none of these problems easier and many of them harder—but more importantly, solving them in a blockchain context requires a set of awkward workarounds that undermine the core premise. So we know the entries are valid, let’s allow only trusted nonprofits to make entries—and you’re back at the good old “classic” ledger. In fact, if you look at any blockchain solution, inevitably you’ll find an awkward workaround to re-create trusted parties in a trustless world.
So, you mean "solving them in a blockchain context requires a set of awkward workarounds that undermine the core premise... In fact, if you look at any blockchain solution, inevitably you’ll find an awkward workaround to re-create trusted parties in a trustless world."
So what problem exactly does blockchain solve for voting that isn't already solved better and more efficiently now?
So now you have to find multiple trusted entities. That you trust to: provide proper audits and handle sensitive personal data
> And then you can follow up with voters,
Who is this you? Another trusted entity? That you have to trust with: handling personal data, be truthful about following up with voters, protecting voter data. And that voters will give you truthful answers. And that this mysterious you doesn't just select "voters" who will tell anything.
> Compared to messy paper ballots, and electronic voting which is centralized and easy to tamper with, a blockchain solution is much more reliable, tamper-proof, and accurate.
So far you have shown that blockchain solution is:
- messy: voter data is no longer anonymised, you need to find multiple trusted agencies to handle personal data.
- entirely centralised: everything is done through centralised agencies: centralised audit, centralised "you" who will follow up with voters etc.
- extremely easy to tamper with: these "agencies" and this "you" can easily do whatever the hell they want with audits and follow ups
- not tamper-proof: the blockhain itself is tamper proof. However, you propose to add a whole host of tamper-prone processes on top of that.
- not accurate: so, distribution of voting rights is not accurate, entry of votes into the blockchain is not accurate, the resulting audit is not accurate, the voter follow up is not accurate, but just because there's blockhain in the middle of all of this, this entire process somehow magically becomes accurate? How so?
My mom was a returning officer for years and I find it horrifying to watch the US gum up their election systems in the name of progress (or, maybe, in the name of election fraud).
Paper is by far the most distributed, understandable, efficient, and secure mechanism we have discovered for obtaining, securing, and tallying votes by humans. It can be practically tamper-proof given a modest amount of trust and scrutiny.
I don't know why, but Americans of every political leaning seem to think that elections are some incredibly hard brain surgery problem. They aren't.
no, we can't
> But paper is extremely inefficient?
efficiency is less important than correctness.
Well, that settles it!
There's no way around the need for trusted institutions in this case.