Hacker News Reader

Comment by zeroxfe | Hacker News Reader

Federated blockchains allow multiple parties in an industry (for example) to maintain a shared trusted database, with no single owner, or single point of failure. (Also, changing immutable data or posting fraudulent transactions requires collusion between multiple parties.)

This is why many large industries like healthcare and finance are actively exploring this space.

View on HN

Distributed databases can be configured to work that way as well.

Why do you need a proof-of-work blockchain? With such a small number of participants doesn't that weaken it's integrity to attacks, especially without capital incentives?

Please someone answer this.

There's nothing that ties a blockchain to proof of work. Proof of work just just one consensus protocol. For instance, JP Morgan's Quorum is working on Raft based consensus. https://github.com/jpmorganchase/quorum/blob/master/raft/doc...

The nodes are federated and you're still calling this a blockchain? What definition of the word "blockchain" are you using? Is this not more commonly called a "distributed database"?

To me, "blockchain" implies the individual nodes don't trust each other, while "distributed database" does.

A "blockchain", taken as a primitive, is essentially an append-only (geographically-)distributed database.

Consider: a Starcraft 1v1 ladder match is, by this definition, synchronized using a "blockchain", whose participating nodes are the two players' computers and the auditing ladder-server instance. That's not a reductio ad absurdam; that's actually what you should be picturing when you say "blockchain" generally: participant nodes, an event stream chunked into blocks, and a consensus mechanism for validating blocks.

Proof-of-work is just one consensus mechanism for blockchains. Mutually-agreed arbitration oracles (as above) is another. First-claim using a global hierarchy of signed-timestamping servers is a third. Etc.

Replying to myself since we hit max comment depth (probably an indicator it's time to move away from this thread anyway). but to address the sibling reply by hudon, yes, a blockchain is a form of a distributed database (maybe highly replicated data base is a better term since every node has the full working data set).

The key trait of a blockchain is that each new entry cryptographically verifies all previous entries. At the end of the day, yes, a blockchain is a distributed db. It's a distributed db that never forgets.

> The key trait of a blockchain is that each new entry cryptographically verifies all previous entries

I see what you're saying. Basically: distributed database + signatures + merkle tree = blockchain.

I usually use this definition: decentralized and sybil-resistant database + signatures + merkle tree = blockchain.

So I think the key trait that turns a distributed database into a blockchain is not the merkle tree, but is its decentralized nature. Anyone can be a transaction validator and no one can prevent transaction validation.

Traditional distributed databases require all nodes to be trusted to achieve consensus (e.g., with Paxos, Raft, etc.) Proof-of-work allows for consensus to occur even if there are malicious nodes -- for up to half the hashrate, which means that major collusion must occur to do something fraudulent.

In these industries the number of participants are in the hundreds -- past the point at which you can trust everyone.

This doesn't work in reality. If you have two companies that need to work with common data it's currently very complex and costly to ensure that both parties can trust the data. That's why trust banks are so big in finance (e.g. Bank of New York, State Street) because it's often cheaper to have a third party you can trust rather than establishing protocols between two companies that auditors approve.

Blockchain can save a lot of money here by making the trusted third party obsolete.

Reply on news.ycombinator.com