You'd use a private, permissioned blockchain over federated SQL databases due to the technical difficulties of synchronizing audit tables across organizational boundaries -- since an enterprise blockchain is append-only, immutable, time-stamped, and each new entry has a hash of the previous view, it overcomes a lot of data integrity issues inherent to a distributed SQL database. None of the companies here will fully trust each other to hold an exclusive copy of the data, so the blockchain here replaces an expensive manual reconciliation step in the event local accounting databases don't match up.

As an external user? Nobody cares, it's not for you, move on.

> since an enterprise blockchain is append-only, immutable, time-stamped, and each new entry has a hash of the previous view, it overcomes a lot of data integrity issues inherent to a distributed SQL database.

And why couldn't a distributed SQL database be append-only, immutable, time-stamped, and implemented so each new entry has a hash of the previous state? (If you own it, just set it up to disallow updates or deletes, and allow inserts only through a trigger / stored procedure that adds the timestamp and hash.)

It could, and then it'd be a blockchain in SQL, like MSSQL's BLOCKCHAIN table type. Those features are definitional to a blockchain.

I take it using that data type in MS SQL Server doesn't use as much electricity as a small country, though?

Yeah but it's not nearly as sexy