[manmanic]

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 regulation. This is fairly niche, perhaps 1% of all interorganizational database applications, but there are certainly cases where it is the right solution. The majority of blockchain projects undertaken still do not make sense, but this is gradually getting better over time.

[hn_throwaway_99]

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 even been a bunch of articles about how smaller coins actually are very susceptible to a 51% attack by a decently funded attacker).

For a private blockchain, though, it never made sense to me as to who would serve the role of the miners with sufficient incentive to prevent a nefarious attacker. If on the other hand you are in a system where the participants agree as to how they will trust each other, well then you'd be back to a situation where the byzantine model isn't really necessary and you can just go back to a cryptographically signed ledger a la the Quantum Ledger DB that AWS just announced.

Would really appreciate someone explaining this one to me!

[JackC]

A useful term here is "Nakamoto consensus," which I think refers to the proof of X thing you're talking about -- consensus schemes that are resistant to sybil attacks among anonymous validators.

And I think you're right -- adding Nakamoto consensus to private blockchains makes no sense, because by definition they don't have arbitrary validators. And without Nakamoto consensus, "blockchain" is just rebranding of old and boring tech.

[manmanic]

There are a variety of formal consensus algorithms uses for enterprise blockchains, but they are all some variant of voting schemes based on validator signatures. Nothing like proof-of-work is needed to ensure that one bad actor, or a small number of bad actors, cannot break the network's consensus. If you have just one validator, like QLDB, then you're back to a centralized scenario.

[Obi_Juan_Kenobi]

The 'corporate blockchain' described above would probably be a federated one. Participants would use private keys to sign and validate transactions, with full knowledge about who else is in the network. It's a simple quorum mechanism, or some elaboration thereof.

It is not 'trustless', but it is decentralized. You're basically relying on a majority of participants to behave ethically and not collude. In a situation where collusion is impractical or has little reward, this can function fine.

An example of this is Blockstream's 'Liquid' crypto which is validated by crypto exchanges. The security model of this coin isn't great compared to Bitcoin, but it arguably has advantages over the simple custodian model.

[wmf]

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.

[judge2020]

HN discussion about 51% attacks: https://news.ycombinator.com/item?id=17173051

[JumpCrisscross]

> 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 regulation

If you're operating a legal business, a centralized database hosted by an industry mutual or regulator beats a blockchain.

[manmanic]

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.

[ellius]

I've only worked on a single blockchain application, but this was my experience too. I was actually pretty skeptical when I was told we'd be working on it and figured it was just a hype thing, but the use case involved a B2B process that was well-established and used a paid intermediary to correlate data across businesses. We were pretty happy with the result. I doubt we'll ever see a middleman-free decentralized utopia, but I agree that it's a technology with some genuine applications.

[davidgerard]

What was it and where? If what you're saying is true, then this is noteworthy and I'd love to look more closely at the details.

[maxxxxx]

Sounds a little like the NoSQL trend where everybody jumped on it only to find out that NoSQL is only applicable for a few use cases.

[autokad]

I dont use NoSQL that much, but I also dont use relational databases much either. most of my work is in pyspark / spark on top of s3.

[nihil75]

what?!?!? I hope that's sarcasm.

[brianbreslin]

I've always seen it as the following equation: is the cost of distrusting the other parties in the transaction lower than the cost of running a decentralized ledger? if yes, you shouldn't use blockchain. this is obviously oversimplification but i think you get my point.

[rayvy]

Yea sometimes I believe the word "enterprise blockchain" makes about as much since as a "dry rain". Basically saying that the problems that blockchain solves are usually not problems that enterprises run into often, or can't solve using some readily available alternative (e.g., SQL). Blockchain clearly satisfies a need. It's just that the great majority of enterprises clearly don't have that need.

[Demigod33]

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

Is NIST correct?

[narrator]

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.

[fwip]

How does the blockchain keep brokers from lying?

[AndrewKemendo]

I've never encountered a system where an un-trusted middleman didn't get out-competed, driven out by the buyers or (in one case) actually killed.

Hasidim don't seem like they have that problem.

[obtino]

Wasn’t this type of stuff around well before the hype of the blockchain? E.g distributed hash tables?

[AndrewKemendo]

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 regulation

Technology can't solve this problem.

If multiple entities need to coordinate inside a mutually used product don't trust each other, then the problem is structural and needs to be solved with interpersonal, regulatory or political action.

[marssaxman]

Annnnd... if you have a structural problem which cannot be corrected via interpersonal, regulatory, or political action, then what do you do?

[darawk]

Yep, i've been trying to explain this to people on here for quite a while now. This is correct. Blockchains allow data and co-operation to be domiciled nowhere, which allows competitive actors to agree and co-operate.

It also enables otherwise untrusted actors to make trustable claims, bypassing the gatekeepers that would otherwise have mediated those claims. One tangible example is ICOs bypassing not just regulators, but banks and the financial industry that would normally have had to underwrite them. Obviously this particular example has some serious kinks to work out, but the ability to bypass the corporate gatekeepers (not so much the regulators) has value, I think.

[6nf]

So can you help the authors of this article with their quest to find any success stories at all?

[Alex3917]

> This is fairly niche, perhaps 1% of all interorganizational database applications, but there are certainly cases where it is the right solution.

So I personally think DLT is going to be one of those multi-quadrillion dollar technologies that come around every few hundred years. The real benefit of DLT is that it enables new types of human relationships. So thinking about it in terms of what percentage of your existing databases should be replaced by it isn't going to give an especially impressive result, because by definition your existing databases are going to model your existing relationships.

Think about what percentage of the stuff in your house you would own without the invention of double entry accounting. Unless you happen to have some veggies from the farmer's market or a sweater one of your relatives knit you, the answer is probably 0.00%. It simply isn't possible to manufacture things like the iPhone without double entry accounting, because without double entry it would be impossible to form the sorts of human relationships needed to produce such a complex product. And if we asked someone to take a look at all the stuff in their house a couple hundred years from now, I'm guessing that a similar 0.00 percentage of the stuff they own will have not have been created as the result of DLT.

The fact is that once DLT becomes ubiquitous it will no longer be cost competitive to manufacture and distribute products using only the sorts of relationships and techniques enabled by double entry accounting. And if anyone even tries it's going to be like bringing a knife to a gunfight.

[Jakawao]

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?