So what I imagine when we talk about a single database is just some mapping of stock shares to owner. So to keep track of who owns what share, when some shares gets transferred you just update each row accordingly. (Imagine a stock with 10 total shares and X sells to Y shares #1, #2, #3, you'd just update the table and set owner=Y where share id is in (1, 2, 3))
But for such important financial data you don't want to just update your table and throw away your history. You'd like to also keep a record of what changes occurred. Maybe you'd like to audit your database, and find out the path of ownership from which a current owner obtained their shares. Maybe you'd like to make your history immutable, so as to not have headaches later on trying to validate the current state, or to discourage tampering with the database.
So now you have a datastore where the current state relies on an ever-growing stack of immutable changesets. This sounds exactly like what we talk about when we talk about blockchains. There are people who define a blockchain more strictly (e.g, The Blockchain(TM) with decentralization and crypto), but I think the author was going for the former meaning.
That is to say, you can implement a blockchain and still be using a single well-designed and well thought-out database.
> So what I imagine when we talk about a single database is just some mapping of stock shares to owner.
Mmhmm. Keep simple things as simple as possible.
> So now you have a datastore where the current state relies on an ever-growing stack of immutable changesets. This sounds exactly like what we talk about when we talk about blockchains.
Well, if that's what a "blockchain" is, then git [0] was doing blockchains way before they were cool.
> There are people who define a blockchain more strictly (e.g, The Blockchain(TM) with decentralization and crypto)
I can see not having a distributed ledger, but if you eject the cryptographic part of it then you don't get any of the tamper resistance. Without that, all you have is a linked list. And -as we all know- "linked list" is a much less sexy phrase than "blockchain".
[0] And -if we drop the cryptographically verifiable history part- pretty much every VCS ever.
> now you have a datastore where the current state relies on an ever-growing stack of immutable changesets. This sounds exactly like
A ledger! A concept which goes back to at least the Sumerians, and can now be efficiently implemented with a variety of technologies - databases, version-control systems, log-structured messaging systems, even good old fashioned files.
> what we talk about when we talk about blockchains.
Er, no. A blockchain is specifically a ledger where the entries are certified by a distributed proof-of-work mechanism. A blockchain is useful where the parties contributing to the ledger don't trust each other, have no way to establish trust with each other, have no trusted intermediary, but are willing to found trust on the cost of computation.
That isn't the situation that the financial industry is in - there, it is a lot of existing trust, it is fairly easy to establish trust, there are plenty of trusted intermediaries, and the amounts involved mean that founding trust on computation would be astronomically expensive. A blockchain would be a really bad fit here.
It also sounds like Git and other version control systems with hash chains.
What Bitcoin did different was adding chain selection using accumulated proof-of-work, incentivized using scarce digital tokens within the same database.
But for such important financial data you don't want to just update your table and throw away your history. You'd like to also keep a record of what changes occurred. Maybe you'd like to audit your database, and find out the path of ownership from which a current owner obtained their shares. Maybe you'd like to make your history immutable, so as to not have headaches later on trying to validate the current state, or to discourage tampering with the database.
So now you have a datastore where the current state relies on an ever-growing stack of immutable changesets. This sounds exactly like what we talk about when we talk about blockchains. There are people who define a blockchain more strictly (e.g, The Blockchain(TM) with decentralization and crypto), but I think the author was going for the former meaning.
That is to say, you can implement a blockchain and still be using a single well-designed and well thought-out database.