4 ms·

> you either need a way to roll-back the change (which removes most/all of the benefits of an append-only structure like a blockchain) Blockchains are not inhe

> you either need a way to roll-back the change (which removes most/all of the benefits of an append-only structure like a blockchain) Blockchains are not inherently immutable or even append-only. What they guarantee (assuming the consensus scheme is working) is that you'll be aware of all the data in the chain or the fact that some of it is missing; the idea that blockchains are inherently immutable is a big misconception that treats blockchains like they're magic. In a database, if you are forced to delete data, you'll go ahead and delete that data. You's probably also record the fact that you deleted that data in some kind of auditing log to be able to audit compliance with those deletion requests, as well as detect illegitimate deletions. In a blockchain, you can do the exact same thing, but with better controls: add a block to the blockchain that contains machine-readable instructions telling all nodes processing the blocks to delete the data if they have a copy. Once every node has done that, even though the blockchain still commits to that data, the data itself is unavailable, thus complying with the requirement to delete it. Essentially we now have a dangling pointer: there will be a digest in the chain, but the data that was hashed to produce the digest is no longer available. The blockchain is of course no longer able to be validated in the same way as before, but what you can validate is the fact that the deletion process was followed properly. E.g. you might have rules that state 2-of-3 senior admins have to use their signing keys to sign off on a deletion request. A similar example of this principle exists in Git: you can do a shallow checkout that doesn't contain all prior history. Recentish versions of Git handle this quite well: every operation will succeed if it doesn't happen to process the missing history. Similarly, if every git repo is in fact a shallow repo, with some history deleted, that data will gone. At the low level, this works because practically all blockchains make use of merkle trees. Rather than the hash of a block b_n being calculated as Hash(b_n), you instead have a header that commits to a merkle tree of data items. Thus you can still validate that the headers are connected without actually having all the data (extra credit problem: is this always a good thing?). 1) By "commit", we mean that the blockchain headers contains a hash digest of some other data; the headers are committed to the data they hashed, because if that data was changed the hash digest would change, rendering the headers invalid.

Klathmon 8y ago
I'd argue at that point it's not a "blockchain", since you are removing one of the major points for using the data structure (the ability to verify the chain without trust). If you are just going to rely on a central authority to say which blocks should be "ignored" (in other words, which hashes should just be trusted), then why use a blockchain at all? It's just a very slow, complicated, expensive append-only log file. The only benefit a blockchain provides (for the sake of this discussion) is it's ability for someone to verify it without trust from the genesis block all the way to the most current. You take that away, it's not a blockchain anymore.
- petertodd 8y ago
  > If you are just going to rely on a central authority to say which blocks should be "ignored" (in other words, which hashes should just be trusted), then why use a blockchain at all? Even if I ultimately have to kotow to the central authority, I still want to be able to audit what they're doing. Similarly, there is no such thing in the real world as a trusted central authority: the central authorities themselves are groups of people who don't fully trust each other, and thus want to be able to do effective internal auditing. You're line of argument could also be used to argue that we don't need to audit banks at all. > It's just a very slow, complicated, expensive append-only log file. The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself. Distributed databases already make use of complicated log files to achieve consensus between nodes and for auditing; adding hashes to the entries in those log files is relatively easy, and as cryptographic hashing is quite fast, doing that doesn't incur much of a performance hit. Most importantly, in a centralized environment, you can fairly easily use standard sharding techniques to make all of this scale well - which is the same way very large databases scale anyway.
  - hartator 8y ago
    > You're line of argument could also be used to argue that we don't need to audit banks at all. That's the whole goal of blockchains though, don't rely on central systems, banks, authorities, audits, or any control. Like someone has to decide the request to be forgotten is legitimate at some point, and that alone defeats the upside of the blockchain. > The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself. Having the full blockchain history saved vs. only last state saved like regular databases, it's obvious blockchains are more resource intensive.

Klathmon 8y ago

I'd argue at that point it's not a "blockchain", since you are removing one of the major points for using the data structure (the ability to verify the chain without trust). If you are just going to rely on a central authority to say which blocks should be "ignored" (in other words, which hashes should just be trusted), then why use a blockchain at all? It's just a very slow, complicated, expensive append-only log file. The only benefit a blockchain provides (for the sake of this discussion) is it's ability for someone to verify it without trust from the genesis block all the way to the most current. You take that away, it's not a blockchain anymore.

petertodd 8y ago
> If you are just going to rely on a central authority to say which blocks should be "ignored" (in other words, which hashes should just be trusted), then why use a blockchain at all? Even if I ultimately have to kotow to the central authority, I still want to be able to audit what they're doing. Similarly, there is no such thing in the real world as a trusted central authority: the central authorities themselves are groups of people who don't fully trust each other, and thus want to be able to do effective internal auditing. You're line of argument could also be used to argue that we don't need to audit banks at all. > It's just a very slow, complicated, expensive append-only log file. The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself. Distributed databases already make use of complicated log files to achieve consensus between nodes and for auditing; adding hashes to the entries in those log files is relatively easy, and as cryptographic hashing is quite fast, doing that doesn't incur much of a performance hit. Most importantly, in a centralized environment, you can fairly easily use standard sharding techniques to make all of this scale well - which is the same way very large databases scale anyway.
- hartator 8y ago
  > You're line of argument could also be used to argue that we don't need to audit banks at all. That's the whole goal of blockchains though, don't rely on central systems, banks, authorities, audits, or any control. Like someone has to decide the request to be forgotten is legitimate at some point, and that alone defeats the upside of the blockchain. > The reason why Bitcoin is slow and expensive is because of the proof-of-work and decentralization, not because of the blockchain itself. Having the full blockchain history saved vs. only last state saved like regular databases, it's obvious blockchains are more resource intensive.