I am exploring the feasibility of Algorand and blockchain technology in general to store criminal history and other case information from court proceedings. But a large issue with many blockchains is immutability. Record sealing and expungement procedures in some USA states would necessitate the deletion of certain records, and that obviously cannot occur with true immutability. And a subsequent entry that the previous information is no longer valid defeats the ultimate purpose of sealing and expungement.
Can Algorand deal with this situation and delete some entries when necessary? Perhaps in a permissioned version?
I dont see issue with immutability… Every system that handles it right now do not delete it completely from the database for the auditing purposes. It is the system that exports the persons criminal records that lists all persons crimes and if some is already “not to be considered” it just does not add it to the export.
And i am sure there is no way to alter historic data in the chain, however you can set boxes and store in the box only live data.
The statutes in several US states explicitly require that expunged records are “destroyed so that they are permanently irretrievable.” So, true immutability would be a concern in some situations as I see it.
To my knowledge algorand is true immutabile as it is even resistant against the quantum computing for the history. Each archival node must be able to retrieve full information from other archival nodes. It would be possible to modify the indexers so that you will not get to that data easily but the bytes stored there are stored in immutabile way and the block bytes will not change.
It is the common practice from all blockchains otherwise the blocks would not follow each other, so any modification of the block data would lead to inproper syncing of the chain, and thus it would not be called blockchain.
I wonder how they do audits if someone did not perform the removal action “on accident”
But personally i would not store on the blockchain any perosnal data either. With GDPR you have the same issue. Its ok to use zero knowledge proofs or some hashes of documents, but dev must be pretty sure that even that might lead to issues as the original documents may leak.
This is a GDPR problem and no, Algorand in it’s public, permissionless form cannot handle it.
You could get around it in another way by storing the exact criminal procedure off-chain and only putting a hash checksum commitment to it on-chain. I made AlgoArchiver to deal with this kind of scenario: http://algoarchiver.onrender.com
However, that might still be too much since the hash checksum stored might still be considered enough to be in violation.
You could upgrade the solution by committing a hash of the text (e.g. in a .txt file) + some kind of salt, some extra kind of secret data. So even if someone has the file they wouldn’t be able to link it to the commitment on the chain. However if someone demands the records you could provide them with the file + salt, then they could manually compute the hash checksum for the combination and confirm that it aligns with what’s on the chain. Then you would need to trust that they would delete the salt and not make it publicly known.
Regarding a ZKP solution, ZoKrates can be used to create Groth16 zk-SNARKs that are validatable by the Algorand blockchain. This particular example shows how someone can prove to someone else that they know of a hash-pre image without actually revealing the pre-image: Proving knowledge of a hash preimage - ZoKrates
In other words, it could allow someone to prove that they have the text record corresponding to a specific hash checksum commitment on-chain, without actually handing over that text record.
I haven’t put much thought into how it could be useful in this case however, since the point is to reveal the text records.