3 ms·

The main innovation is that blockchain is decentralized and yet still verifiable. A public SQL database is in nature centralized. Even if you were to try and sh

The main innovation is that blockchain is decentralized and yet still verifiable. A public SQL database is in nature centralized. Even if you were to try and shard it out to everybody in the network you have the difficult time of cross verifying such data heavy records.

purerandomness 8y ago
> A public SQL database is in nature centralized Why would a SQL database be centralized in nature? Just as your n nodes hold the entire blockchain, you would have n nodes holding the entire SQL database. Of course, you could have a blockckain only on one node, centralised. That wouldn't make it inherently "centralized", however. Same with SQL databases.
- mike_hearn 8y ago
  There aren't any decentralised SQL engines really. There are distributed databases that provide SQL-like abilities, like Spanner, but they're optimised for huge scale and not low trust. They're still expected to be run by a single organisation, not a p2p network of many organisations. I am the lead engineer on Corda, which is an open source 'enterprise' (i.e. institutional/industrial) blockchain-inspired platform. But if you don't like the B word you can think of it as a decentralised database that can be queried using SQL. The intro to the technical white paper describes some of the issues with "just run a public SQL database" approach: https://www.corda.net/content/corda-technical-whitepaper.pdf https://www.corda.net/content/corda-technical-whitepaper.pdf Why not just use a shared relational database? This would certainly solve a lot of problems using only existing technology, but it would also raise more questions than answers: • Who would run this database? Where would we find a sufficient supply of angels to own it? • In which countries would it be hosted? What would stop that country abusing the mountain of sensitive information it would have? • What if it were hacked? • Can you actually scale a relational database to fit the entire financial system? • What happens if the Financial System™ needs to go down for maintenance? • What kind of nightmarish IT bureaucracy would guard changes to the database schemas? • How would you manage access control? So, it's ultimately a system that tries to address these questions and many others too. If you can solve these issues then you can suddenly actually propose an entire market putting all data into a single database engine, and at that point things can get a lot more robust and efficient. But it just wouldn't be politically possible on any sort of scale to do that with Postgres.
  - purerandomness 8y ago
    Thanks for the writeup and the whitepaper. I find it hard to follow the distinction between decentralised and distributed, especially since all of the points above would apply to your implementation, as well: All the decentralised networks rise and fall with enough political pressure, becasue they all have a weak spot - some form of organizational structure that needs to be kept alive by some entity. In your case (from the whitepaper): > A network map service that publishes information about nodes on the network. The legal entity that will maintain this service will be faced with enough pressure to shut it down once the state in which this entity happens to operate in implements laws that happen to render some of the content in the database illegal. If someone provides a solution to this, that would be groundbreaking. Until today, no such thing exists.
    - mike_hearn 8y ago
      Why not jump on the Corda mailing lists and follow along as we work on these things? The network map is a component I've spent a lot of time thinking about and working on, to make it more and more decentralised over time. Because yes a lot of users flag the same thing you have. Corda has some simple features to mitigate this. For instance nodes have an additional-node-info directory where you can drop NodeInfo files. These act as overlays on the data received from the zone's network map. If the zone operator removes a party from the network map for some reason (maybe a court order, maybe a commercial dispute, or whatever) then you can just drop their NodeInfo file in this directory and it'll be as if they're still in the map. So the idea is that the zone operator acts as a coordinator and provider of advice, but it doesn't have real control - node operators can always override whatever advice it's giving out.

purerandomness 8y ago

> A public SQL database is in nature centralized Why would a SQL database be centralized in nature? Just as your n nodes hold the entire blockchain, you would have n nodes holding the entire SQL database. Of course, you could have a blockckain only on one node, centralised. That wouldn't make it inherently "centralized", however. Same with SQL databases.

mike_hearn 8y ago
There aren't any decentralised SQL engines really. There are distributed databases that provide SQL-like abilities, like Spanner, but they're optimised for huge scale and not low trust. They're still expected to be run by a single organisation, not a p2p network of many organisations. I am the lead engineer on Corda, which is an open source 'enterprise' (i.e. institutional/industrial) blockchain-inspired platform. But if you don't like the B word you can think of it as a decentralised database that can be queried using SQL. The intro to the technical white paper describes some of the issues with "just run a public SQL database" approach: https://www.corda.net/content/corda-technical-whitepaper.pdf https://www.corda.net/content/corda-technical-whitepaper.pdf Why not just use a shared relational database? This would certainly solve a lot of problems using only existing technology, but it would also raise more questions than answers: • Who would run this database? Where would we find a sufficient supply of angels to own it? • In which countries would it be hosted? What would stop that country abusing the mountain of sensitive information it would have? • What if it were hacked? • Can you actually scale a relational database to fit the entire financial system? • What happens if the Financial System™ needs to go down for maintenance? • What kind of nightmarish IT bureaucracy would guard changes to the database schemas? • How would you manage access control? So, it's ultimately a system that tries to address these questions and many others too. If you can solve these issues then you can suddenly actually propose an entire market putting all data into a single database engine, and at that point things can get a lot more robust and efficient. But it just wouldn't be politically possible on any sort of scale to do that with Postgres.
- purerandomness 8y ago
  Thanks for the writeup and the whitepaper. I find it hard to follow the distinction between decentralised and distributed, especially since all of the points above would apply to your implementation, as well: All the decentralised networks rise and fall with enough political pressure, becasue they all have a weak spot - some form of organizational structure that needs to be kept alive by some entity. In your case (from the whitepaper): > A network map service that publishes information about nodes on the network. The legal entity that will maintain this service will be faced with enough pressure to shut it down once the state in which this entity happens to operate in implements laws that happen to render some of the content in the database illegal. If someone provides a solution to this, that would be groundbreaking. Until today, no such thing exists.
  - mike_hearn 8y ago
    Why not jump on the Corda mailing lists and follow along as we work on these things? The network map is a component I've spent a lot of time thinking about and working on, to make it more and more decentralised over time. Because yes a lot of users flag the same thing you have. Corda has some simple features to mitigate this. For instance nodes have an additional-node-info directory where you can drop NodeInfo files. These act as overlays on the data received from the zone's network map. If the zone operator removes a party from the network map for some reason (maybe a court order, maybe a commercial dispute, or whatever) then you can just drop their NodeInfo file in this directory and it'll be as if they're still in the map. So the idea is that the zone operator acts as a coordinator and provider of advice, but it doesn't have real control - node operators can always override whatever advice it's giving out.