Hacker News Reader

Comment by Animats | Hacker News Reader

The use case for this is what?

For a new pump & dump scheme

Not much really. Blockchains are a cool solution to a very specific problem. Trying to use them for everything as a general solution, as the author suggests, is not very practical.

I believe anything that uses blockchain. Use cases can range from record keeping to tracking data or flow of transactions. It can also span across multiple and diverse industries like healthcare, transportation and logistics, government welfare benefits distribution et al maybe even voting.

> Use cases can range from record keeping

I am told that an old-style SQL database can do that just fine. With a lot less overhead.

Blockchain is an open distributed ledger protocol. I don't see how that fits with SQL?

Am I missing something?

The question is exactly what does a blockchain get you for record keeping that overrides the many downsides. You can even have a central entity maintain their own database and provide a stream of edits to it for others to replicate if they want to prove that records are being kept accurately, without having to solve the issues a blockchain solves.

The "open distributed" part comes at a tremendous cost. A Bitcoin-style blockchain is a distributed database where you can't trust any of the other nodes, so you need a consensus mechanism that provides hard financial incentives for the majority to agree quickly. Proof-of-work systems like Bitcoin and Ethereum solve this by having miner nodes consuming energy and transaction parties paying them for validating transactions. Because the miners must get paid increasingly much as competition amongst them increases, transactions won't be getting any cheaper.

Some types of data are valuable enough to pay miners to validate and store the transactions, but usually it doesn't. To take one of your examples: why should government welfare benefits data be stored on a blockchain? Does it make any sense for a local government to reward foreign miners for storing their data on a global blockchain? In this instance, a replicated SQL database seems much more sensible.

(You might say that a blockchain without proof-of-work mining can also solve this -- but then you have to ask what is the essential difference between a blockchain where you implicitly trust some parties, and a traditional distributed database? Why do it the hard way when you've already compromised on the decentralized part?)

Exactly. All that I would add to that is:

1) you can add hashes etc to a database to verify data integrity. The cost is minimal compared to a distributed consensus mechanism. See https://en.wikipedia.org/wiki/Merkle_tree

2) Consensus mechanisms among untrusted parties open you to the infamous "51% attack" which should disqualify this design for much government data. But if you only allow trusted parties, why bother with proof of work at all?

I gave a talk in November at GOTO Berlin about why a globally consistent transactional database is a better fit for most distributed ledger applications than a blockchain.

If you are interested in the relational database approach, the middle of the talk (and the associated example code) might be a fun place to start. https://blog.fauna.com/talk-video-build-a-serverless-distrib...

The biggest problem with current blockchain implementations is the excessively low block size because of a irrational fear of centralisation yet mining profit just for bitcoin today is in the billions which is high enough to equip thousands of datacenters every year with hardware that can process 10GB blocks or even larger.

Visa processes 50000 transactions per second. Imagine each of them of them requires a single byte to store through black magic. If you do the math you will realise that 50kb per second over 10 minutes is 30 megabytes per block. 2MB blocks are not even remotely enough.

Reply on news.ycombinator.com