Kako obrisati ono što ste anchorali?

To remove data that has been anchored, you must separate it into two parts: the content remains in a regular store under your control, while the commitment is stored on the chain. The commitment only proves that the content existed at a certain height in a certain sequence and that the sequence around it has not been altered. The chain only receives a commitment to that data: a hash of a record or a root Merkle tree over multiple records anchored together.

When you remove the data and its salt, the commitment no longer reveals what it was. The ledger records what happened and points to the record via an identifier, but the proof ties these two together without exposing the content. The hash of names, email addresses, or ID numbers safeguards the information well and often fails to do so.

The possibilities are limited: those who can find candidates can calculate their hashes and compare them. Add a random salt to each record, generated per record, and keep it in an external store, never on the chain. The commitment becomes a hash of the salt and the content. Without the salt, the value on the chain cannot be reproduced from the assumption.

What does this mean for deletion? When a deletion request is accepted, the content and its salt are removed from the external store. The commitment remains on the chain, but nothing can be recalculated that corresponds to it. The ledger still shows that the record existed at a certain height, in a certain sequence, and that the sequence around it has not been changed.

A reviewer can still verify that the history has not been tampered with, but cannot learn from the chain what was written in that record. For most business cases, this is precisely the desired boundary: integrity remains publicly verifiable, while personal data remains under your control where it can be managed. What you lose and what you need to decide are two consequences to record in the project.

First, when content disappears, the possibility of proving what was written also disappears. Deletion and proof move in opposite directions, and for some retention obligations, this may outweigh the other. Second, whether a hash is still considered personal data is a legal question that depends on the case, the input, and what else can be linked to it.

This judgment is made by the data protection officer (DPO), not the architect. The practical rule is brief. Before anchoring any content for the first time, decide which fields could ever need to be deleted, keep them outside the chain, and write a deletion procedure in the ledger design. Afterward, it is a migration. What should you regret anchoring in your ledger? The full text can be found at https://www.omarbaruzzo.it/hr/blog/cancellare-un-dato-ancorato.