Uploaded image for project: 'Fabric'
  1. Fabric
  2. FAB-5097

[GDPR support] On demand delete of private data prior to block-to-live policy based on a delete transaction

    XMLWordPrintable

Details

    • Story
    • Status: In Progress
    • High
    • Resolution: Unresolved
    • None
    • v2.x
    • fabric-ledger
    • None

    Description

      Ability to delete private data from private data storage and private state database on demand by a client request, without having to wait for the typical blockToLive period prior to purging. The blockToLive mechanism is insufficient for use cases that need to be compliant with GDPR, where data must be deleted upon a subject's request.

      Option for transaction resulting from DelPrivateData() chaincode API to purge key from peer's private data store and transient store on all peers, in addition to deleting from private state database on all peers.

      Implementation notes:

      Private data store

      The private data store is keyed by block number and transaction index within the block and stores the private writes for a transaction. The private data write for a certain key/value can be removed from this block/tran index, leaving the store in the same state as when the private data was simply missing. We may need to add a marker to indicate that the private data was intentionally deleted and not simply missing. There is also a missing data tracking index that would need to be updated if that key was already marked as missing on the peer (that is, remove the missing entry for any newly purged keys).

      To know which block/tran index to purge from private data store, we can look in the private state database. The private state database entry for the key would indicate the last block/tran index 'version' that updated the key. The private writeset can then be removed from the block/tran index in the private data store. Note that prior transactions in the private data store may have also updated the key previously, therefore we may also need a new index that tracks all historical writes for a certain key (this is already maintained for public writes to satisfy GetHistoryForKey() queries, a similar index may be needed for private writes).

      Transient store

      The transient store is keyed by txid and holds private data until the tx is committed. Therefore for committed private data, the entries should already have been removed. There is potential that the key in question is in the transient store for another uncommitted transaction. If that transaction eventually gets committed, then it would re-create the private data key. This may happen in the case of a blind write. But for the more typical read/writes, the uncommitted transaction would likely get invalidated rather than committed if seen in a future block transaction due to the deletion in the current transaction causing a MVCC invalidation. The uncommitted transactions in transient store may never be seen in a future block transaction, in which case the entry will anyways get purged automatically based on the core.yaml transientstoreMaxBlockRetention setting (default 1000 blocks).

      Private data pulling

      Other peers may attempt to pull the private data from this peer, if they are behind in block height or were missing the private data. This peer should respond to the request that the data has been intentionally purged. Currently the requesting peer will try other peers if the private data cannot be found. This logic will need to be updated to stop the retries if it is told that the private data has been intentionally purged.

      Attachments

        Issue Links

          Activity

            People

              calanais Matthew B White
              denyeart David Enyeart
              Votes:
              10 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

                Created:
                Updated: