Ask HN: How does consensus work in an enterprise blockchain? | Hacker News Reader

Ask HN: How does consensus work in an enterprise blockchain?

33 pointsthisisit34 comments

We have seen a lot of focus given to bitcoin's PoW and the electricity usage. This got me thinking how the enterprise offerings like Quorum, Hyperledger work exactly? Are they like a PoS model?

Edit: Based on the inputs, I wanted to add couple more questions.

If the consensus is based on a set of trusted accounts, why are people using the enterprise blockchain stuff still talk about blockchain being "trustless"?

Second, if it is only about a set of shared ledger with multiple trusted parties, what is wrong with an API layer integration? What exactly is the value creation for a full fledged system?

Third, bitcoin blockchain defends against a miner getting hacked by making everyone do PoS. Sure coins will get stolen.

But, if we have a permission-ed server which can add stuff to an enterprise blockchain doesn't it make the whole thing a lot less secure?

View on HN

As your edit notes, trust solves a lot of the technical hurdles that Bitcoin and Etherium and other protocols intended for use against adversaries must leap.

Many of the proposed and actual uses of blockchain are layered on top of existing trust networks. For example inter-connected electrical grids operated by separate companies already trust each other and already have working settlement mechanisms. Potentially a blockchain can improve/simplify/quicken an existing flow of settlements between trusted parties by eliminating phonecalls, faxes, snail mailed bank drafts, and so on. It may reduce manual processing and human error and banks in the middle.

As a technology, blockchain may be more like double entry accounting or an abacus than the many other things that the word "technology" tends to conjure up in our minds.

> Second, if it is only about a set of shared ledger with multiple trusted parties, what is wrong with an API layer integration? What exactly is the value creation for a full fledged system?

> But, if we have a permission-ed server which can add stuff to an enterprise blockchain doesn't it make the whole thing a lot less secure?

You're asking the right questions and this is pretty much a summary why the enterprise use is unlikely to use blockchain the same way as the public, if at all. Enterprise/banking may be interested in a distributed ledger as a datastructure, but other tech which provides a similar results already exists.

Unfortunately if you look at most of the "big (company/bank) starts (experimenting with/using) (Bitcoin/blockchain)" news, they very rarely say why and how.

The goal would be to enable co opetition. Think of patent pools, the incentive usually is to own the patent and enforce it, inside of patent pools however , the goal is to get to application. So a collection of non trusting entities can have a shared ledger of record.

That most certainly is the pull, which Enterprise blockchain cos sell as simplified back office.

Will it work like that in production ? No clue

When the Bitcoin paper originally came out, it used the word 'blockchain' to specifically mean a 'trustless distributed blockchain' where consensus is reached via mining, and that is susceptible to a 50% + 1 attack, and where the mining nodes are individual businesses that have no reason to trust each other except that the game is set up in a way that it is in their self-interest to secure the blockchain.

However, there's a use for the word 'blockchain' which is 'distributed blockchain', which is a data structure that is a chain of blocks where each includes a hash of the previous one - it's distributed amongst machines, but those fundamentally trust each other (like in case of JPMorgan chain), so there's no reason to use a 'trustless distributed blockchain'. You can't set up a miner and join Quorum and make money securing it. In such a case, quorum is probably solved just using standard distributed database algorithms like Paxos or Raft.

JPM's Quorum is originally a fork of Ethereum though.

Sure, but it's permissioned. Not everyone can join and mine.

Huh? Bitcoin white paper does not have the word block-chain in it.

Yet it describes the blockchain. It talks about blocks, it refers to them in a chain. While true that the word block-chain doesn’t exist, it isn’t relevant to OP’s point (since the paper clearly defines the blockchain concept now used so prevelantly).

It may not have the "blockchain" exactly but it certainly does have blocks and mentions chaining them together.

It’s based on a quorum of white-listed accounts that are allowed to sign blocks.

Worth watching this talk on Ripple's consensus algorithm by its architect: https://www.youtube.com/watch?v=7abKUs9tYZg and related whitepaper: https://ripple.com/files/ripple_consensus_whitepaper.pdf

I have no affiliation with Ripple or XRP, just enjoyed the fairly technical nature of the talk.

> How does consensus work in an enterprise blockchain?

It doesn't, because blockchain doesn't solve consensus problem.

What's the point of using a blockchain then?

There’s tons of answers to this, but one example I’m interested in is as a good shared, accessible audit log for data throughout an organization. Just having a stable history for all data helps with investigation and master data management.

In this case consensus isn’t really necessary because all participants are trusted and should rarely differ (since they all have the same boss at some level).

I agree. But working at a huge company I can honestly say they don't really want an immutable ledger. They want to fudge and change things.

I suppose maybe it depends on the organization. I’ve worked at companies that do want an immutable ledger. But probably not have it be public.

Typically a ledger should be immutable. That's what retains its auditability. Any fudging/changing should be done through reverse entries that explain why the reversal occurs.

To tell which document (transaction) of a given pair correlated ones was issued earlier, which is called "timestamping". But you don't need consensus (as in Byzantine generals problem) to do that, you just need timestamping protocol.

Maybe explain a little more? Obviously in your opinion the OP is confused, but this answer is short and unhelpful.

First and foremost: what is consensus problem?

A trustless blockchain most certainly does. https://news.ycombinator.com/item?id=15915957

It most certainly doesn't. You even confuse blockchain and Merkle trees, and call into existence some weird term "distributed blockchain".

But then, consensus problem is a problem of establishing a specific value for almost all participants. Which implies that the value is established, which means that the protocol terminates. Blockchain was not designed to ever terminate, so it's not a consensus protocol even if for no other reason.

Otherwise, what parts of blockchain exactly establish a common value among participants and what exactly is this common value?

What? There is consensus on the public blockchain every few seconds + block depth. It's called Nakamoto consensus, so yes blockchain 'solves' the problem.

In smaller chains, there can certainly be consensus, it just won't be as trusted as a public chain and 51% attacks are potentially more feasible due to it having a smaller economic barrier.

> What? There is consensus on the public blockchain every few seconds + block depth. It's called Nakamoto consensus, so yes blockchain 'solves' the problem.

It's a name used for Bitcoin's protocol. It doesn't mean it's consensus.

How does the established value by this "consensus" protocol look like? And why do you consider it established, when other participants can have a totally different view of the list of documents in the protocol, or your view can change completely with next message? How is it an agreed value? And at what point should we look at the views of two different participants to see the same value?

And how does it relate to Lamport's original publication about the consensus problem?

The established value of the consensus is the transactions contained within the block. It's established because it's what the network accepted, regardless of individual node states.

That's the point, one should not have to consider the values of other nodes to reach consensus. If the network agrees on something, that's consensus. If a certain node doesn't, that's their problem.

It's agreed because that miner solved the block problem first. If you have a different view, you must fix it. This is how it achieves consensus.

Not sure what specific consensus problem Nakamoto consensus doesn't solve, but it does provide a consensus based on the specific rules of the network. So yes, it's a consensus system. You might want to be contrarian and dispute what consensus means to you. But that's what it means to to the miners and that's what matters.

> The established value of the consensus is the transactions contained within the block.

Which of them? Because every node has a slightly different view and doesn't know how it differs from anybody else's view.

> That's the point, one should not have to consider the values of other nodes to reach consensus. If the network agrees on something, that's consensus. If a certain node doesn't, that's their problem.

The problem is that every node has slightly different view. You can't tell "this is the agreed value", because no particular node has this value as its state. Yet somehow it emerges as network's agreed value? By what means (algorithm) anybody can take a list of transactions and say "this is the network's agreed value"?

Not to mention that the list of transactions constantly changes, you didn't address the problem that agreed value requires the protocol to terminate first.

> It's agreed because that miner solved the block problem first. If you have a different view, you must fix it. This is how it achieves consensus.

In what way is "solve block problem" consensus?

> Not sure what specific consensus problem Nakamoto consensus doesn't solve,

Yes, this is typical problem with blockchain enthusiasts. They're usually too uneducated and don't know the fundamentals, like the definition of consensus problem. I pointed you to Byzantine generals paper already, it should have been easy to find even with just "consensus problem Lamport" keywords.

Just because it doesn't fit into your contrarian view on consensus it doesn't mean it doesn't provide consensus.

Nakamoto consensus solves the Byzantine problem quite well. The list of transactions doesn't not constantly change? Are you saying there is no consensus as to the value of the first blocks?

I get that it's cool to be contrarian and it makes people feel smart to badmouth blockchain. But Nakamoto consensus does reach a consensus on value that is accepted by the network.

It's like saying a voting election didn't matter because certain people didn't participate.

> Just because it doesn't fit into your contrarian view on consensus it doesn't mean it doesn't provide consensus.

You do realize that this "my contrarian view" is what computer science calls "the consensus problem", right? And that "my contrarian view" comes from a highly regarded publication that's thirty years old?

> Nakamoto consensus solves the Byzantine problem quite well.

Explain to me how. Byzantine generals problem comes with a rigorous proof that network cannot agree on a single value if the cooperating nodes don't outnumber the adversarial ones by more than 2:1. The blockchain guarantees its functions with merely 50% + 1 of cooperating nodes. Something doesn't add up if blockchain was intended to solve consensus problem.

> I get that it's cool to be contrarian and it makes people feel smart to badmouth blockchain.

Oh, but I don't badmouth blockchain. I think it's quite ingenious cryptosystem. I only badmouth blockchain enthusiasts, and the undereducated ones at that.

Blockchain was never intended to be a consensus protocol, it was always a timestamping protocol. We had a number of those before, but blockchain is the first one that doesn't use trusted third party. This is the ingenuity of blockchain, not consensus that blockchain doesn't solve.

And then the idea behing Bitcoin, that a digital cash protocol (of which we had some number before, too) can be built on top of published and timestamped transactions, which together form a ledger. This is smart as well. But it's still not a consensus protocol.

> But Nakamoto consensus does reach a consensus on value that is accepted by the network.

Despite that nobody can tell what value exactly was agreed upon? And despite that you can't designate any specific point in time that the agreement is reached? I fail to see how is this "consensus".

It's quite simple really. Do all miners [eventually] agree on the value of a block? Yes? That's a consensus.

True there are other types of consensus that are perhaps 'fairer' but that's not the issue here.

So yes, it is a consensus protocol. It's called Nakamoto consensus, and it's perfectly fine for its purpose.

> Do all miners [eventually] agree on the value of a block? Yes? That's a consensus.

It's amazing how many things you got wrong in such a short statement. First, a program can't say when this "eventually" is. Then the "agree" part is wrong, too, because it can change just like that (because of forks), which even changes the history, not just a single transaction or group of them. And then there's also "all miners" part, which even read as customary universal quantifier ("all" meaning "most of them") falls apart if you remember that this needs to be assessed by a program with limited knowledge.

It's not a consensus in any computer related meaning that one could think of.

This is just silly. By these arguments even block #1 has no consensus and has not terminated.

Because "it might fork" that's why it's not a consensus? lol, ok buddy.

Dude, you haven't provided any usable criteria to declare any particular block as "agreed upon". All you said was "eventually", and even that has flaws. It's not something to argue against well known mathematics.

Don't argue with us. Argue with satoshi. https://www.mail-archive.com/cryptography@metzdowd.com/msg09...

You seem like you understand more than I do. ELI5 why agreeing on an ordering of timestamps on transactions is not consensus, but agreeing on a single value such as "attack" or "retreat" is consensus.

Reply on news.ycombinator.com