The actions that an employee could perform in any database would be limited by their account permissions. Blockchain doesn’t change this. I pointed out a retrospective mechanism because a completely internal blockchain wouldn’t prevent tampering either.
You end up with a very complex database account management.
I agree in general. Fully internal databases should not be blockchains.
But if external access is required at any point then there may be a blockchain use case.
It’s not complicated at all. It’s basic database access management and it’s been a thing for decades without issue. If external access is required then those parties are given restricted access appropriate for their job and their actions are logged in the audit log in case any inappropriate actions were taken by them and need to be reviewed/reversed. These are solved problems and blockchain adds nothing there. The only case that blockchain helps is in a system where you have a large number of random participants and you want transactions to be enforced by work done/computing power or stake. This is why cryptocurrency has been the only practical use case for blockchain, with the word “practical” doing a lot of work, hence the diagram in the post we’re all discussing.
If external access is required then those parties are given restricted access
So a human needs to get involved.
inappropriate actions were taken by them and need to be reviewed/reversed.
Lack of finality slows processes.
These are solved problems and blockchain adds nothing there.
Two improvements/use cases given above.
The only case that blockchain helps is in a system where you have a large number of random participants
I.e. Access without human authorisation
and you want transactions to be enforced
Finality.
This is why cryptocurrency has been the only practical use case for blockchain,
Supply chain tracking
Royalty payments
Renewable energy tracking
Ticketing
Etc.