3 ms·

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

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.

SideburnsOfDoom 8y ago
> 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.
- godelmachine 8y ago
  Blockchain is an open distributed ledger protocol. I don't see how that fits with SQL? Am I missing something?
  - vertex-four 8y ago
    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.
  - pavlov 8y ago
    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?)
    - SideburnsOfDoom 8y ago
      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 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?
    - jchrisa 8y ago
      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-distributed-ledger-without-the-blockchain https://blog.fauna.com/talk-video-build-a-serverless-distrib...
    - imtringued 8y ago
      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.

SideburnsOfDoom 8y ago

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

godelmachine 8y ago
Blockchain is an open distributed ledger protocol. I don't see how that fits with SQL? Am I missing something?
- vertex-four 8y ago
  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.
- pavlov 8y ago
  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?)
  - SideburnsOfDoom 8y ago
    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 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?
  - jchrisa 8y ago
    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-distributed-ledger-without-the-blockchain https://blog.fauna.com/talk-video-build-a-serverless-distrib...
  - imtringued 8y ago
    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.