4 ms·

Ever try to share a conventional database between multiple different companies or organizations? It's not practical. It seems more complicated than going with

Ever try to share a conventional database between multiple different companies or organizations? It's not practical. It seems more complicated than going with a blockchain solution (or will be as blockchain deployment tools mature). The adage that 'if parties are trusted, than go with a conventional DB' doesn't hold water anymore. If you need to share a database with other companies, it inevitably leads to contracting a third party solution to manage the data entry between all parties, which means you now have to trust this one entity and there's a single point of failure. Hyperledger, blockchain, and the like eliminate the need for third party management. A few engineers at each party needs to set up the new service, and now you don't have to worry about central points of failure, you have built in redundancy, and you save money by not having to use a data management service that exists to make money off of you.

nearting 8y ago
> Ever try to share a conventional database between multiple different companies or organizations? It's not practical. Not practical how? It seems like this criticism can only be applied to usability, but that's not a technical shortcoming. > If you need to share a database with other companies, it inevitably leads to contracting a third party solution to manage the data entry between all parties, which means you now have to trust this one entity and there's a single point of failure. This criticism seems a bit underspecified. While it's true that having a single entity to handle data entry results in a single point of failure, but what's the failure model? Do we assume that this single entity might be malicious? Or are we assuming that the entity handling data entry isn't familiar with the types of failures they may encounter, and thus hasn't taken steps to mitigate the effects of those failures? Both of those scenarios, given the context of sharing data among organizations, seems unrealistic. > Hyperledger, blockchain, and the like eliminate the need for third party management. A few engineers at each party needs to set up the new service, and now you don't have to worry about central points of failure, you have built in redundancy, and you save money by not having to use a data management service that exists to make money off of you. The claims you make here are correct: (1) the consensus protocol provides a decent mechanism for writing to the database, (2) redundancy insulates against loss of data, and (3) the open nature of the protocol means you don't have to use a for-profit service. However, there are far more efficient ways to achieve these things without relying on blockchains. If everyone that could write to the database is known, and what you want is simply to guarantee the integrity of the database, there are better data structures than a linear chain of hashed, batched events (which is all that a blockchain is, at its core).
- wmf 8y ago
  The failure mode that keeps happening is that the trusted central third party charges high fees to access the database.

nearting 8y ago

> Ever try to share a conventional database between multiple different companies or organizations? It's not practical. Not practical how? It seems like this criticism can only be applied to usability, but that's not a technical shortcoming. > If you need to share a database with other companies, it inevitably leads to contracting a third party solution to manage the data entry between all parties, which means you now have to trust this one entity and there's a single point of failure. This criticism seems a bit underspecified. While it's true that having a single entity to handle data entry results in a single point of failure, but what's the failure model? Do we assume that this single entity might be malicious? Or are we assuming that the entity handling data entry isn't familiar with the types of failures they may encounter, and thus hasn't taken steps to mitigate the effects of those failures? Both of those scenarios, given the context of sharing data among organizations, seems unrealistic. > Hyperledger, blockchain, and the like eliminate the need for third party management. A few engineers at each party needs to set up the new service, and now you don't have to worry about central points of failure, you have built in redundancy, and you save money by not having to use a data management service that exists to make money off of you. The claims you make here are correct: (1) the consensus protocol provides a decent mechanism for writing to the database, (2) redundancy insulates against loss of data, and (3) the open nature of the protocol means you don't have to use a for-profit service. However, there are far more efficient ways to achieve these things without relying on blockchains. If everyone that could write to the database is known, and what you want is simply to guarantee the integrity of the database, there are better data structures than a linear chain of hashed, batched events (which is all that a blockchain is, at its core).

wmf 8y ago
The failure mode that keeps happening is that the trusted central third party charges high fees to access the database.