> Yes in the sense that event sourcing systems typically [are]... "append only"
However, I'd caution that this is not the same at all as cryptographic / blockchain style tamper proofing. I can still go into the database and change things myself, or create a new one altogether.
There are some interesting ideas in the article. I.e. making a peg to a blockchain, but that won't solve the throughput / trust dilemma.
Yes in the sense that event sourcing systems typically have an "append only" data store which gives a full log over all state changes. That makes event sourcing particularly attractive for finance, gambling, etc.
But surely the append only property is rather weak, unless it is backed by physically read-only storage? Otherwise the system itself may not be able to change existing events, but a rogue admin or other bad actor could.
Yes, the idea behind a blockchain is a merkle tree of events, metadata and salt that hashes with a predetermined number of 0's (the difficulty) as a prefix.
If you wanted to make your event stream more tamper-proof you could also introduce a merkle tree-like row which hashes the current event, the previous hash and a secret key. Any tampering of the data would need this key and would need to recompute future events.
It's still not perfect because with the key this is easy to do.
Yes, event sourcing is just a loosely defined pattern. It does make tamper proofing a bit easier due to its log like nature. I know some systems do use physically "append-only" storage.
Is tamper proofing typically a feature of event sourcing systems? If so, how is it implemented?