HN: Shaan Ray
Feb 10
Blockchains versus Traditional Databases
https://towardsdatascience.com/blockchains-versus-traditional-databases-e496d8584dc
To understand the difference between a blockchain and a traditional database, it is worth considering how each of these is designed and maintained.
Distributed nodes on a blockchain.
Traditional Databases
Traditional databases use client-server network architecture.
MD: There is no such thing as a traditional database. Databases existed way before there was a client-server orientation. But we’ll assume your client-server model for purposes of this critique.
HN: Here, a user (known as a client) can modify data, which is stored on a centralized server. Control of the database remains with a designated authority, which authenticates a client’s credentials before providing access to the database.
MD: Do you think the DNS (Domain Name Service) databases fit this model?
HN: Since this authority is responsible for administration of the database, if the security of the authority is compromised, the data can be altered, or even deleted.
MD: Can we replace “authority” with “protocol” or “process” and still assume we are talking about the same thing?
HN: Traditional Databases.
Blockchain Databases
Blockchain databases consist of several decentralized nodes. Each node participates in administration: all nodes verify new additions to the blockchain, and are capable of entering new data into the database. For an addition to be made to the blockchain, the majority of nodes must reach consensus. This consensus mechanism guarantees the security of the network, making it difficult to tamper with.
MD: Don’t “shared” and “distributed” databases have this trait? If not, how can they possibly work? How about “journaled” databases?
HN: In Bitcoin, consensus is reached by mining (solving complex hashing puzzles), while Ethereum seeks to use proof of stake as its consensus mechanism. To learn more about the difference between these two consensus mechanisms, read my earlier post.
MD: See: https://moneydelusions.com/wp/2018/02/13/what-is-proof-of-stake/
HN: Integrity and Transparency
A key property of blockchain technology, which distinguishes it from traditional database technology, is public verifiability, which is enabled by integrity and transparency.
MD: Actually “public” is a relative term. Corporations have databases that do this without blockchain technology for their own “public” that can be very large and use very distributed database technologies. And airline reservations do this through federation with franchised travel agents … all without blockchain.
HN: Integrity: every user can be sure that the data they are retrieving is uncorrupted and unaltered since the moment it was recorded
MD: Only if they are believers. The only users with anything close to such an assurance are the “developers” who supposedly know “all” the complicated mechanism involved. A distributed public transparent data organization, where “anyone” can see everything gives better assurance. This is the mechanism favored by a “proper” MOE process.
HN: Transparency: every user can verify how the blockchain has been appended over time
MD: By using “trusted” API’s. There’s no way they can know the API’s they’re using should be trusted. They’re too complicated … and they’re not open.
HN: A map of Dashcoin masternodes distributed across the world.
CRUD vs Read & Write Operations
In a traditional database, a client can perform four functions on data: Create, Read, Update, and Delete (collectively known as the CRUD commands).
MD: And if the database is distributed and journaled they can do this without the “delete” and “update” … a necessary requirement for “true” transparency.
HN: The blockchain is designed to be an append only structure. A user can only add more data, in the form of additional blocks.
MD: And this causes unnecessary and undesirable latency (which is killing Bitcoin right now). Ideally, every transaction journaled into the database is “related” by hash to every other “related” transaction. What is needed is a hash linking the journal entries … and that is very easy to provide by including an input and output hash into the hashing process itself. Most transactions in a so-called blockchain block have no relevance to each other. It makes more sense to keep “related” transaction chains together rather than “all” transaction chains. This reduces latency and synchronization problems enormously.
HN: All previous data is permanently stored and cannot be altered. Therefore, the only operations associated with blockchains are:
Read Operations: these query and retrieve data from the blockchain
Write Operations: these add more data onto the blockchain
MD: Which I have described above is not “novel” at all. We have had it with journaled distributed databases for a very long time now. We have many of the mechanisms in the various forms of RAID (Random Array of Inexpensive Drives).
HN: Validating and Writing
The blockchain allows for two functions: validation of a transaction, and writing of a new transaction. A transaction is an operation that changes the state of data that lives on the blockchain. While past entries on the blockchain must always remain the same, a new entry can change the state of the data in the past entries.
MD: This is deceptive. The data in past entries never changes. The state of the current data changes by adding transactions to previous states. And you can mitigate corruption of this process with an input and output hash linking them and included in the hash of the new transactions. No block is required. Just a journal entry with two hashes … an input hash and an output hash which includes the input hash. The input hash can be verified back in time as far as the user chooses to do so … and all users my choose to do so any time they want to prove the process integrity.
HN: For example, if the blockchain has recorded that my Bitcoin wallet has 1 million BTC, that figure is permanently stored in the blockchain.
MD: A “real” money process has no such thing as a “bitcoin” wallet. It only has to prove that something claiming to be a bitcoin is not a counterfeit. A huge flaw in the bitcoin process is the fractioning of bitcoins. This is not different in end result than the fractioning of Indian (native American) lands … where they have been fractioned so many times the parcels are too small to be of use and they cannot be practically re-aggregated.
HN: When I spend 200,000 BTC, that transaction is recorded onto the blockchain, bringing my balance to 800,000 BTC.
MD: A “real” and “proper” process cares nothing about the money once it is created by traders. It only cares that it cannot be counterfeited and that the promise creating it is delivered as promised. No money is in circulation without a relation (albeit not direct) to a trader’s “in-process” promise. For any given creation, money does not exist before the promise, nor after the promise is fulfilled. In the mean time it is the most common object in every simple barter exchange … because it works. And it works because it never changes value over time an space. The “process” or “protocol” guarantees it and cannot be manipulated.
HN: However, since the blockchain can only be appended, my pre-transaction balance of 1 million BTC also remains on the blockchain permanently, for those who care to look. This is why the blockchain is often referred to as an immutable and distributed ledger.
MD: With a “real” process, the money “used” by traders is totally anonymous and unaudited. It is usually just a ledger entry in a “trusted” account … trusted by the traders using it. It may temporarily be in use as a coin or currency and returned to a ledger entry. The coin and currency are just uncounterfeitable tokens that when converted to a ledger entry are placed in storage and have no value at all. “Creation” and “destruction” and “default” and “interest” collection are a different matter (than “usage”) entirely. The traders are known and singular. They aren’t groups. They aren’t aliases. Their locations are known and they can be visited. That’s what keeps the process honest and leads other traders to “use” the money. As an example, we all “create” money when we buy a house on time. The documents recording our “promise” are recorded by the county clerk and available for all to see. We know how to do this. We also know how to streamline it (by using things like credit bureaus and title companies). As we pay back our “mortgage” we return money and it is destroyed. We don’t return the same money we created … that’s just not necessary nor can it work in practice.
HN: Centralized vs. peer to peer.
In short, the difference is Decentralized Control
Decentralized control eliminates the risks of centralized control. Anybody with sufficient access to a centralized database can destroy or corrupt the data within it. Users are therefore reliant on the security infrastructure of the database administrator.
MD: And as I have illustrated, that is not the difference, because a distributed journaled database of any kind “must” have decentralized control. What is central and known is the “process” or “protocol”.
HN: Blockchain technology uses decentralized data storage to sidestep this issue, thereby building security into its very structure.
MD: The blockchain has nothing to do with centralization or decentralization. It has everything to do with mitigating “forging” and “counterfeiting” and it does it unnecessarily inefficiently, expensively, slowly, and in an unnecessarily complicated fashion.
HN: Though blockchain technology is well-suited to record certain kinds of information, traditional databases are better suited for other kinds of information. It is crucial for every organization to understand what it wants from a database, and gauge this against the strengths and vulnerabilities of each kind of database, before selecting one.
MD: A journaled database can just manage documents or links … or links to links … or links to links to links. That is irrelevant. What is relevant is transparency of what it is managing and who is interacting with it. That’s what journaling does.