[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.

[jacobr1]

> rebranding of old and boring tech

A distributed merkle-chain database is still pretty innovative. A good example is git. I think what many private groups want is a "binary git for transaction data". Everybody can review their own copy of the shared chain with signing of new links in the chain.

Now that isn't really a full blockchain, but is a different kind of thing from a central RDMS.

[sfescape]

That is a blockchain, and provides the validation and history integrity that is core to (and where the name 'blockchain') comes from.

[hn_throwaway_99]

Except the issue is that Git, which includes validation and history integrity, was invented in 2005 and predates the publication of the bitcoin whitepaper by 3 years.

The point being that all the hype about "blockchain everywhere" came about because of bitcoin. If people are now starting to refer to just the "hash of blocks with previous blocks" (i.e. the "Timestamp Server" section of the original bitcoin whitepaper) as blockchain withOUT the proof of work/stake part, well then you really are just rebranding old tech as blockchain, because it was the proof of work part that was really the new thing in bitcoin.

[mcguire]

Can someone correct me if I'm wrong?

Proof of work is required for distributed consensus; without that you need a centralized repository like GitHub or Linus to bless the current state of the database?

[tim333]

Well proof of work is used to get consensus and prevent double spend in cryptocurrency though there are other mechanisms being tried like proof of stake.

With Git for code you don't really need consensus - I can have my fork and you can have yours.

[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.

[wslh]

The problem is that having a non-BFT consensus is the same that using database nodes and if you use BFT consensus you don't have the performance required for most use cases. BFT-SMaRT supposely achieve 80k tps for a few nodes but when you scale to more nodes the performance degrades substantially.

Another issue against the DLT hype is that the blockchain does not provide security where 90% of the whole architecture is outside the blockchain, less if there are many few nodes.

[dlubarov]

There might be some constant factor penalty, but we can shard BFT systems much like we do with Paxos etc. See Shasper for example -- it won't have any practical limits on throughput.

[wslh]

Shasper[1] "Note: This is an experimental project. Everything will break, and it may disappear without any notice!" (sic).

Until we don't see a community working on adversarial attacks, we will not know if it is secure of not. There is concrete research about BFT since 1982.

[1] https://github.com/paritytech/shasper

[dlubarov]

Is your concern that the algorithms involved in schemes like Shasper might not be correct, or that their economic assumptions about attacks might fail?

I think it's very unlikely that any of the theoretical ideas behind Shasper are incorrect. Casper itself is simple and comes with a simple proof, and it's similar to an old algorithm by DLS [1], which also comes with a proof. Sharding does introduce some other machinery, like VDFs for randomness (specifically [2]), but that has been vetted by plenty of cryptographers such as Dan Boneh's group.

So even though there aren't any large-scale deployments of BFT algorithms yet, the approach is widely thought to be sound. I'm working on a blockchain based on sharded BFT, as is Ethereum, RapidChain, NEAR Protocol, and others.

It's always possible that our economic assumptions will fail, but they're not radically different from Bitcoin's. You can attack Bitcoin by buying 51% of all hash power, or you can attack a BFT system by buying 34% of all stake. Either way it comes down to making an assumption about the attacker's funding.

[1] https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf

[2] https://eprint.iacr.org/2018/623.pdf

[wslh]

> Casper itself is simple and comes with a simple proof

When I read the updates about Casper[1] there are plenty of issues presented, so don't sure why you are saying Casper itself is simple.

Fine you are working in the "Sigma Network", we are working with one of the projects mentioned there.

[1] https://medium.com/prysmatic-labs/

[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