03-09-2023, 06:20 AM
Personally I'm of the opinion that, unless you're attempting to make another currency, a blockchain is not going to be better than just having a database and using the features they already have to track changes. Like you've identified blockchains are not a very good database due to their nature, and in this situation I don't think they give you any advantages to make up for their disadvantage.
That said, I think the actual "blockchain" part is really just the hash chain - where each new entry in the chain contains a hash of the entry before it, creating a linked-list of all the entries in the chain. Because the hash of an entry includes all the data in the entry as well as the hash of the previous entry, you cannot change anything in previous entries in the chain without also changing the hashes of every entry after that point. This is Ex. exactly how `git` works and verifies that your copy of the code history matches what is held elsewhere, it simply verifies that your history ends in an entry with the same hash.
The actual validation of whether a new entry is allowed on the chain at all is separate in my mind from the blockchain itself, but also I think it depends a lot on the kind of data you plan to store, there's lots of "shortcuts" you can take to make it easier. For example I believe Bitcoin solves this problem by requiring transactions to spend _all_ the tokens from a previous transaction to an address (even if that means just sending some of the tokens back to the same address they were at). This means verifying a transaction doesn't require looking up every transaction associated with that address to count how many tokens they still have, instead transactions have to list the outputs of other transactions as inputs that are getting spent, and verifying the new transaction only requires looking up the outputs of the referenced transactions and verifying they match what is listed.
Since the new transaction has to spend _everything_ from the referenced inputs, the transactions used as input never need to be worried about again and you will simply reference the outputs of the new transaction. To prevent someone from spending their tokens twice (IE. Using the output of a transaction as an input to two separate transactions) I think you still have scan every transaction in the history between "now" and where in the past the referenced transaction is, but that's not too bad because if the transaction appears as an input _anywhere_ you know a double spend is happening, you don't need to worry about how much is being spent.
That said, I think the actual "blockchain" part is really just the hash chain - where each new entry in the chain contains a hash of the entry before it, creating a linked-list of all the entries in the chain. Because the hash of an entry includes all the data in the entry as well as the hash of the previous entry, you cannot change anything in previous entries in the chain without also changing the hashes of every entry after that point. This is Ex. exactly how `git` works and verifies that your copy of the code history matches what is held elsewhere, it simply verifies that your history ends in an entry with the same hash.
The actual validation of whether a new entry is allowed on the chain at all is separate in my mind from the blockchain itself, but also I think it depends a lot on the kind of data you plan to store, there's lots of "shortcuts" you can take to make it easier. For example I believe Bitcoin solves this problem by requiring transactions to spend _all_ the tokens from a previous transaction to an address (even if that means just sending some of the tokens back to the same address they were at). This means verifying a transaction doesn't require looking up every transaction associated with that address to count how many tokens they still have, instead transactions have to list the outputs of other transactions as inputs that are getting spent, and verifying the new transaction only requires looking up the outputs of the referenced transactions and verifying they match what is listed.
Since the new transaction has to spend _everything_ from the referenced inputs, the transactions used as input never need to be worried about again and you will simply reference the outputs of the new transaction. To prevent someone from spending their tokens twice (IE. Using the output of a transaction as an input to two separate transactions) I think you still have scan every transaction in the history between "now" and where in the past the referenced transaction is, but that's not too bad because if the transaction appears as an input _anywhere_ you know a double spend is happening, you don't need to worry about how much is being spent.