Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blockchain study finds zero success rate and vendors don't call back

theregister.co.uk

Post reply on HN
Print view View original

61–70 of 247 posts

Re: Blockchain study finds zero success rate and vendors don't call back

#61

Post by russdpale »

this_user wrote: post #28
Animats wrote: post #9

That's bad. I thought someone would be using a blockchain for some kind of back-end settlement system somewhere, but apparently not. On the ICO front, the SEC is now cracking down effectively. First they went after the outright frauds, such as the coin backed by nonexistent land and diamonds. They won in court. Then they went after the ones that promised big returns and didn't deliver. The SEC won again. That settled…

> That's bad. I thought someone would be using a blockchain for some kind of back-end settlement system somewhere, but apparently not. The problem in that area is not the previous lack of available technology, it is institutional inertia. You don't need a blockchain to speed up settlements, because the technology to do it did exist before. What you need is buy-in from a bunch of old and conservatively run institution…

> The primary fallacy of all these blockchain proponents is only seeing problems as technical in nature when they really lie somewhere else. The same applies especially to smart contracts.

This is a great point, especially with smart contracts, the problem of the wet code is massively more complex than that of the dry code.

Re: Blockchain study finds zero success rate and vendors don't call back

#62

Post by wmf »

hn_throwaway_99 wrote: post #25
manmanic wrote: post #8

I've been working on DLT / enterprise blockchain technologies since 2014 and have insight into hundreds of projects, a small number of which made it to live production. Here is the bottom line: yes, it's mostly hype, but this technology does have genuine use cases - when you want to build an interparty database-driven application, and cannot find a suitable place to put the database, because of business concerns or r…

Can you let me know how these "private" blockchains utilize proof of X to determine consensus? E.g. proof of work, or proof of stake, or something else? The thing I never understood with private blockchain tech is that the "traditional" blockchain (i.e. Bitcoin) relies on proof of work, and the only way this is viable is to have tons of resources working on these proofs so that you don't get a 51% attack (there have…

If the participants trust each other not to gang up on a minority but otherwise don't trust each other then BFT consensus is appropriate. As the OP said, that's around 1% of cases but maybe those cases are valuable.

Re: Blockchain study finds zero success rate and vendors don't call back

#63

Post by fwip »

narrator wrote: post #43
manmanic wrote: post #8

I've been working on DLT / enterprise blockchain technologies since 2014 and have insight into hundreds of projects, a small number of which made it to live production. Here is the bottom line: yes, it's mostly hype, but this technology does have genuine use cases - when you want to build an interparty database-driven application, and cannot find a suitable place to put the database, because of business concerns or r…

The only successful applications of business blockchain I've seen is in businesses where nobody trusts the brokers. For example, the diamond business has to keep track of where the diamonds came from and nobody trusts the brokers to not lie, so blockchain works here.

How does the blockchain keep brokers from lying?

Re: Blockchain study finds zero success rate and vendors don't call back

#64

Post by wmf »

manmanic wrote: post #29
JumpCrisscross wrote: post #26

Earlier quoted context omitted.

> in some cases an industry mutual doesn't exist, and the regulator doesn't want to manage the database. Then what? If you're at the scale where broad co-ordination is a problem, you're at the scale where the big boys can arrange a meeting. Alternatively, if you're at a scale where someone can get everyone on a blockchain, you're at the scale to create an industry organization.

I'm sorry but this does not always apply in the real world. Someone getting everyone onto a blockchain is a one-time project, perhaps with an annual maintenance fee. Running an industry organization is an order of magnitude (or two) more expensive. Trusting someone to build an (open source) application is not the same as trusting them to centrally host it.

Every successful cryptocurrency has had protocol upgrades which require governance and I imagine private blockchains will be similar. You can't just let it run. So if you have an industry organization to perform ongoing governance of the blockchain then it is probably cheaper to have that organization run a database.

Re: Blockchain study finds zero success rate and vendors don't call back

#65

Post by asynchrony »

Alex3917 wrote: post #50
Jakawao wrote: post #41

Earlier quoted context omitted.

I can’t tell if you are being sarcastic or not, so I assume this is a serious comment. Can you share some examples of use cases where DLT is going to be transformative?

I mean a good example of the need for DLT is the fact that no one in the country can buy romaine lettuce right now. Does it really make any sense whatsoever that no one in the country can eat lettuce for the next couple months just because one farm got contaminated with E. coli?

Putting lies into a blockchain doesn't make them true. Lettuce can still kill you in a post-blockchain society.

Re: Blockchain study finds zero success rate and vendors don't call back

#66

Post by wmf »

mrtksn wrote: post #35
manmanic wrote: post #23

Earlier quoted context omitted.

Yes, that's true. But in some cases an industry mutual doesn't exist, and the regulator doesn't want to manage the database. Then what? It can be cheaper and easier to deploy a blockchain than to build the necessary organizational structure to run a central database. Like I said, it's niche but it happens.

Can you please give a more specific example to illustrate the case? From my perspective, blockchains are suitable for two things: People who want to misbehave(therefore they don't have legal recourse, independent of the morality of the extralegal actions) and people at war with each other that still need to have a relationship with each other. It's kind of the perfect technology for a collapsed civilization or the re…

people at war with each other that still need to have a relationship with each other

So Wall Street banks?

Re: Blockchain study finds zero success rate and vendors don't call back

#67

Post by Demigod33 »

manmanic wrote: post #8

I've been working on DLT / enterprise blockchain technologies since 2014 and have insight into hundreds of projects, a small number of which made it to live production. Here is the bottom line: yes, it's mostly hype, but this technology does have genuine use cases - when you want to build an interparty database-driven application, and cannot find a suitable place to put the database, because of business concerns or r…

https://m.imgur.com/a/RlUj9Ed

Is NIST correct?

Re: Blockchain study finds zero success rate and vendors don't call back

#68

Post by derefr »

marcosdumay wrote: post #54
derefr wrote: post #40

Earlier quoted context omitted.

How about a thing that's almost-but-not-quite a blockchain? E.g. a decentralized multi-master Event Sourcing datastore. No proof-of-work, no mining, no ledger. Anyone who can connect to the network (i.e. is whitelisted) can append whatever they like, and it'll get replicated to everybody. But nobody can delete/overwrite (without losing consensus); and every event is signed by its emitter. It's just an append-only log…

> It's just an append-only log file that happens to exist in several (geographically distant) places at once. That's the idea. Just add a proof of causality for the transactions that span more than one peer, and you've got a blockchain.

No. A log file under Paxos, for example, is not a blockchain.

A blockchain is a chain of blocks. A block is a persistent record of all the information required for the consensus process, which is held onto by a node after the consensus process has completed for that node. A new blockchain node bootstrap-syncs to the network by just receiving blocks at random from peers and then evaluating the consensus rules against those blocks in order to decide what its deduced copy of the "chain" shall look like. And you can never throw those blocks away (just keeping the transaction log), either, because a new peer might want to bootstrap itself from you.

This is not how multi-master sync in e.g. etcd or Postgres works. In those, consensus is a process that happens between all the nodes registered to a given cluster at any point in time. Each consensus-step happens between a known, fixed set of peers (fixed for the duration of that step, that is), consuming a fixed set of data that must be the same on all peers (the database before the update), and producing a new artifact (the updated database) that should be identical on all peers. After the consensus step completes, the inputs required to re-evaluate that particular consensus step are discarded by all peers. You can't go back and "watch history" happen again. You can only know what you've got right now.

But, luckily, since what you've got right now is an append-only file, you can just read it and see everything that's happened historically. It's just a logical history, though, not the history of the consensus process itself.

New nodes in such a system don't re-evaluate history to "reach consensus." They just pick a bootstrap peer to trust and slave themselves to it, synchronizing until they're an exact mirror of it. But—because all the nodes in the cluster keep their state in lockstep under consensus anyway—every node that is "in consensus" is as good as any other node that is "in consensus" for bootstrapping from. (And if you happen to bootstrap from a node that is lying about being "in consensus", then you'll quickly find that you can't obey the consensus protocol with the rest of the cluster using the data you bootstrapped.)

A blockchain is a very specific kind of distributed database architecture. Just having a distributed append-only database does not automatically make something a blockchain. You can have distributed append-only databases that aren't blockchains.

(Heck, there's an even more trivial case: a distributed append-only database owned by one party. How do you build that? Just deploy a master and some read-replicas, and tell the master to be append-only by policy! It should be pretty obvious, I hope, that that is not a blockchain.)

Re: Blockchain study finds zero success rate and vendors don't call back

#69

Post by fwip »

TACIXAT wrote: post #16

I used blockchain in a project successfully, but it is not a distributed consensus application. My problem was file sharing. Torrent files send a big list of SHA1 hashes, one for each piece of the file. I replaced that idea with a single block which contains the hash of the next block (as well as two other blocks so verification isn't linear one block to the next). This allows a single block to represent the entire f…

You might wanna look into Scuttlebutt, Dat or IPFS. All help solve that initial problem you mentioned, but in different ways.

Re: Blockchain study finds zero success rate and vendors don't call back

#70

Post by asynchrony »

bognition wrote: post #4
krmmalik wrote: post #2

I've spoken to a number of vendors and come across similar findings as well. Though of course, this is just observational on my part and not a detailed investigation or study, but I have been getting much the same impression. There's a lot of unnecessary hype and people jumping on the bandwagon just because it's currently a buzzword. That said, I still have a lot of faith in what Blockchain will eventually be able to…

> I still have a lot of faith in what Blockchain will eventually be able to achieve. What does this even mean? Its a really beautiful solution its just lacking a good problem.

Faith is required to sustain belief in promises that are never delivered.
Post reply on HN