Proposal: Tombstoning Transactions In Hyperledger Indy

Stephen Curran, Sovrin Foundation�2023.05.09

Tombstone Ledger Transactions – Definitions

Tombstone – Sovrin Glossary

A mark associated with a Transaction to suggest that the Transaction should no longer be returned in response to requests for read access. In the Sovrin Ledger, a Tombstone may be either a Node-Specific Tombstone or a Ledger-Wide Tombstone. Tombstones do not modify the Sovrin Ledger—only the behavior of a Node that serves data from the Ledger and that wishes to honor the Tombstone’s semantics. In the general context of Self-Sovereign Identity, Tombstones are undesirable, as they represent a vector for censorship. However, they may be used by a specific Steward that is forced to comply with a legal demand to stop returning a specific Transaction, such as a Transaction containing data that is locally considered Personal Data or that is illegal or violates the Transaction Author Agreement in some other way. In such a case, other Stewards may not face the same legal demands and may take different action.

Use Cases of Interest

• Private or illegal data on the ledger
• Enabling a response to a “GDPR” type request for data removal, or because illegal data was found to be one the ledger.
• As noted in the glossary – could be global or node-specific.
• Avoidance strategies:
• Where possible, avoid the writing of arbitrary data on the ledger.
• Where possible, verify the structure of data before writing, where possible.
• Remove access to transactions after a length of time on Test Networks to discourage “using Test networks for production/long-lasting applications”
• E.g. transactions older than X months are not readable
• However, some older transactions MUST be readable – e.g. the Trustees and Stewards.

Past Approaches

• JIRA Indy Node issue: Individual Nodes Can Tombstone Data
• Steward node keeps a list of “tombstoned” transactions.
• Request to read tombstoned transaction received.
• Return an error from the node.
• Client may request the transaction from another node, throughout the network.

Proposed New Approach

• Avoid the “node-specific” tombstoning
• Add three new types of configurations:
• NeverReturnTombstone – transaction list.
• AlwaysReturnTombstone – transaction list.
• ReadTransactionAgeLimit – days (0 for always).
• Nodes track updates to the configurations tombstone records.

Logic – something like this:

• On receipt of a Read Request:
• Retrieve transaction.
• If on NeverReturnTombstone list
• Return Error
• If older than ReadTransactionAgeLimit
• If not on AlwaysTombstone
• Return Error
• Return Transaction

Notes

• On receipt of updates to the rules, ensure there is no crossover between “Never” and “Always”.
• Updates to the rules must include a way to add and remove a transaction from the lists.
• E.g. adding a transaction ID twice removes it from the list.
• The transactions are NOT removed from the ledger – they are just not returned to readers.
• Adding nodes and transaction catchup means that the transactions are shared with new nodes.
• Transactions read by services like IndyScan may or may not respect the Tombstone Settings
• The ledger cannot control what they do after they read a transaction.
• They could monitor the ledger, detect such updates and use the data as they see fit.
• Likely, a best practice to at least respect the “Never” list.
• Configuration rules would be implemented comparably to the “Config Transaction Flag”

Discussion…

• Interest?
• Other use cases?
• Thoughts on these use cases?