> 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

> 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. That's the point of cryptocurrencies; that doesn't mean centralized systems can't use the same technology to achieve their own goals. > Having the full blockchain history saved vs. only last state saved like regular databases, it's obvious blockchains are more resource intensive. Depends on how the database is used - lots of databases have usage patterns that are mostly append-only, in which case you're saving the full history anyway. As for the non-append-only parts, such as indexes and running balances, you can always use an architecture where their is either not committed at all in the block headers, or if it is, you just accept that auditors might need to do a bunch of re-computation to precisely check every interm state by replaying the transaction history logs. Now don't get me wrong: this will incure some performance hit. But with good engineering we're talking about things that are maybe half or a quarter as fast, not fundamental scaling problems. That's the kind of performance hit where just buying more hardware isn't a big deal.