TL;DR: personal data off-chain with a per-record random salt; only the commitment goes on-chain. Erase the data and the salt, and the commitment points at nothing.
A decision ledger is useful because its entries cannot be changed after the fact. The same property becomes a problem the first time an entry contains personal data and someone asks for it to be erased. The answer is decided at design time, before the first anchor, and it is not a clever trick on the chain.
Split the record in two
Keep the content in an ordinary store that you control: a database table, an object store, whatever the rest of the system uses. This is where the personal data lives, and where it can be corrected or deleted like any other data. The chain receives only a commitment to that content: a hash of one entry, or the root of a Merkle tree over many entries anchored together. The ledger entry then says what happened and refers to the record by identifier, and the proof ties the two together without publishing the content.
A plain hash is not enough
Hashing a name, an email address or a tax code looks safe, and often is not. The input space is small, so anyone who can guess candidates can compute their hashes and compare. Add a random salt to each record, generated per entry, and store it next to the data in the off-chain store, never on the chain. The commitment becomes the hash of salt plus content. Without the salt, the value on the chain cannot be reproduced from a guess.
What deletion then means
When an erasure request is accepted, delete the content and its salt from the off-chain store. The commitment on the chain remains, but nothing is left that can be recomputed to match it. It is a number that points at nothing. The ledger still shows that an entry existed at a given height, in a given sequence, and that the sequence was not altered around it.
What you lose, and what you still need to decide
Two consequences should be explicit in the design. First, once the content is gone, so is the ability to prove what it said. Erasure and evidence pull in opposite directions, and for some records the retention rules will say which one wins. Second, whether a hash still counts as personal data is a legal question that depends on the case, on the input and on what else can be linked to it. That judgment belongs to your data protection officer, not to the architect.
The practical rule is short. Decide which fields may ever need deleting before the first anchor, keep those off the chain, and write down the erasure procedure together with the ledger design. Afterwards it is a migration.
Which fields in your ledger would you regret having anchored?
Full text: the erasure pattern in full
Articolo originale: https://www.omarbaruzzo.it/en/blog/cancellare-un-dato-ancorato
