I've discovered that some people say "blockchain" when they mean "immutable, distributed, cryptographically-verified database" -- which is actually a useful thing for many people.
The Byzantine fault tolerance, public consensus, and mining aspects that we associate with "true" blockchains are the parts that people can't find a way to justify and can typically be ignored.
I was talking about this a few months ago with a well-meaning non-techie, who suggested that Uber - the money-burning minicab firm with an app - was an example of a "decentralised system." More than that - it was a model for how blockchain could succeed.
I think they'd never thought about the concept of distributed systems of any sort ever before in their lives.
"It's like blockchain, because anyone can sign up to be an Uber driver!"
"Uh ... anyone can sign up to be a minicab driver."
or the very concept of "open source" only being possible with "blockchain".
When I bought my first screwdriver, a lot of problems seemed like they should be solved by tightening, loosening or adding screws to things. Because I had a screwdriver and damn it, I was going to use it. But often even when we have a fantastic idea, it isn't broadly applicable. Lots of problems I had couldn't be solved with a screwdriver, many more shouldn't be.
This came up for Certificate Transparency. CT uses Merkle hash trees to provide an immutable, cryptographically-verified Log of things it has been shown - in the original application those are X.509 certificates from the Web PKI ("SSL Certificates"). None of the component parts are even modern let alone unprecedented, although arguably it would be less practical without elliptic curve crypto, but nothing like CT itself had ever been done before, and its designers deserve significant praise.
And in the subsequent years as CT was successful we saw not only uptake of CT itself which was good, but also when there was some other problem people would propose solving it with this new magic toy - let's have Whatever Transparency. None of those went anywhere, because the unique recipe for CT is not a universal multi-tool, it solves one very specific problem very well indeed and that's fine.
Sure. Which is, as the parent comment pointed out, rarely one of the things people trumpeting "blockchain" need in the problem domain they're proposing to deploy it.
I don't need global PoW or PoS consensus for my health records.
I need something my health providers and I can agree is authoritative and as accurate as the data entry makes possible. The parent comment's "immutable, distributed, cryptographically-verified database". Something like a shared git repo. Not like a crypto currency.
Without those other "negligible" aspects there is no incentive for anyone to run nodes to validate the chain. There is no blockchain. It's those very things that allow these systems to function.
I completely agree with you. I'm just saying that there's a loophole when you're dealing with people who are obsessed with doing "blockchain for ____". If they understood blockchain from a technical perspective, they'd understand that it makes no sense for their application.
You can still work with those people if you revise the definition for "blockchain" in your mind into something that isn't really a blockchain.
The actual bit that catches the eye of enterprises seems to be solving one of these two problems:
* reconciling all the data in one place
* having a tamper-evident ledger of transactions
The second just puts logs in a 1979-style Merkle tree, and the first is 100% getting organisations working together and doing the hard tech-debt slog of cleaning up your data and formats.
If you have both problems, your problem is enough of a human/business mess that applying a blockchain won't fix any aspect, but may well make it worse.
Occasionally "blockchain" will be useful as a buzzword to get funding.
To kinda-sorta paraphrase myself from last week[1], I suspect that when people say "blockchain", what they typically mean is that they think implementation details are the most important thing, and what the product actually does is just an afterthought.
>Byzantine fault tolerance, public consensus, and mining
Why would I want ANY of these things associated with the system that manages my medical records?
I don't want them to be immutable, if there's an error I want it corrected. Clearly there should be security to control who (my provider) can update them, and perhaps turn on the database transaction log to track what updates were made by whom and when.
I don't want my medical records to be distributed for obvious reasons.
Encrypted, sure, but "cryptologically verified" seems to be overkill as there's little incentive for third parties to try and forge medical records.
Byzantine fault tolerance? Lol. My medical records get updated maybe once per year, by my provider, and no one has an incentive to insert false data.
Public consensus? See above.
Mining? Come on.
99.9% of the time when someone says we should use blockchain, they really just need a database, this is one of those cases.
>> I don't want them to be immutable, if there's an error I want it corrected.
Immutable here means no in-place update, you have to update using an "errata" record. This is the requirement for many type of official documents, even before computers were used.
>> I don't want my medical records to be distributed for obvious reasons.
Distributed here means no single point of failure.
>> Encrypted, sure, but "cryptographically-verified" seems to be overkill as there's little incentive for third parties to try and forge medical records.
Encryption without authentication opens up many types of attack. You almost always want authenticated encryption
>>>Immutable here means no in-place update, you have to update using an "errata" record.
Yes, and people have been building financial systems with relational databases using this journaling principle (updates and deletes handled by inserting new records and timestamping) for decades.
>>>Distributed here means no single point of failure.
Which can be done with most standard RDBMS or NoSQL databases and clustering/sharding. Not that the scale of medical records is anywhere near requiring any of this. Do you really want multiple copies of your personal medical records on some public blockchain?
>>>Encryption without authentication opens up many types of attack. You almost always want authenticated encryption
For financial transactions, sure, but for medical records? For what purpose? Other than me and my provider (and any specialist I select) why would anyone else even need to access my medical records? Who would be faking them?
Make up your mind. First, you said these properties were useless, now you're saying these properties have been in use for a long time using relational database, which means they're really useful.
>> Do you really want multiple copies of your personal medical records on some public blockchain?
No I don't. This thread's starter and I never said that these properties can only provided by "blockchain", neither did we said that "blockchain" should be used. We only said that these properties were useful and people wanted them.
>> For financial transactions, sure, but for medical records? For what purpose? Other than me and my provider (and any specialist I select) why would anyone else even need to access my medical records? Who would be faking them?
For example, a fraudulent specialist with access to your data can modify your prescription so they can steal money from your insurance provider and also take these extra medicine to sell on the black market.
I put "true" in quotes because there are so many competing definitions for blockchain. I agree with other commenters that there is an original definition, but people rarely talk about blockchain these days without having the Bitcoin model in mind.
People tend to use the word blockchain as a near synonym for cryptocurrency, but even as the article in this thread shows, it’s not the only application for it. A blockchain is just a type of data structure, very similar to a linked list, with _some_ additional integrity features.
A lot of the pointless debate and highly opinionated grandstanding that takes place around blockchain is centred around misuse of the word. As far as data structures go, it’s a perfectly reasonable one, and has plenty of uses outside of cryptocurrency. Sure it’s a buzzword, but politicising the use of a particular data structure seems just as pointless as any other kind of dogmatic evangelism to me.
You might come up with a reasonable definition, like "append-only ledger with a consensus mechanism" - but in marketing terms, "blockchain" literally only means "whatever I'm trying to sell you today."
And then there's weasel terms like "blockchain technology", which means "I can't even claim this thing is actually even a blockchain, but it's got a few of the same parts."
I don't think it's fair or relevant to talk about hypothetical marketing definitions of a blockchain here. You wouldn't be discussing the merits of a linked list by mentioning the creative descriptions marketers can come up for it.
I think it's entirely fair to discuss the marketing of a linked list when they keep calling it "blockchain" and assigning nigh-magical properties to it, which is what is happening here.
A blockchain is just a type of data structure. Cryptocurrencies use blockchains, but mining, trustless distributed consensus, fault tolerance, and all these other things are features of cryptocurrency implementations, not essential elements of blockchains.
Volkswagen quite publicly use that very solution from IBM, and there’s numerous other examples of it being used in supply chain management, which absolutely isn’t the only useful application of blockchains.
It’s not even clear if you know what a blockchain is, and your comments on its usefulness are just as extreme and misinformed as the evangelists who say it can be used to solve any problem under the sun.
Link me to the VW thing please? Last I checked there was literally no reason to use blockchain outside of cryptocurrencies since you get the same benefits just using GIT.
Looks like they want to use it to lower traditional auditing costs in developing countries. Not sure how the blockchain tech is supposed to help tracking materials or establish trust in such an environment but that's not really my field - presumably it adds a component of different people creating a digital paper trail that's harder to manipulate. That's an application compliance people in a few sectors seem to like these days, guess we'll see if it actually makes sense over traditional efforts in N years.
> Last I checked there was literally no reason to use blockchain outside of cryptocurrencies since you get the same benefits just using GIT.
How does the data structure of a git repo differ from a blockchain? The only difference I can see is in how it’s used. A blockchain wouldn’t have more than one permanent branch.
Consensus is certainly not a necessary element of a blockchain. A blockchain can just as easily exist under the control of a central authority, as it could under any other circumstances. Unless you mean that you’re still achieving consensus by simply trusting the central authority, which I guess is technically correct, but that’s not how ‘consensus’ is generally used in relation to blockchains, it’s generally used to refer to trustless distributed consensus.
What makes git different from a blockchain? A blockchain is a data structure, and a data structure doesn’t change based on who has permission to write to it.
Those terms don’t have the meanings you’re using. Being a data structure is not a distinguishing factor – try finding a common definition which excludes Git – and there’s no definition of the term which excludes modifications.
I’m not sure why you’re trying to say. The data structure is immutable by design. You can’t modify a git commit. But you haven’t answered my question. What’s the difference between a blockchain, and git?
The Byzantine fault tolerance, public consensus, and mining aspects that we associate with "true" blockchains are the parts that people can't find a way to justify and can typically be ignored.