private data instead of offchain db adapter?

[sschulz-t]

While thinking about using the MongoDB or the internal CouchDB instead of the currently used mysql db I did some investigation how fabric internally uses the CouchDB. I was wondering if it is possible/a good idea to use the private data feature of hyperledger to replace the offchain db adapter. We could use an implicit collection and transient data. Note that I do not want to set up a shared collection between two parties, every party has their own. This will also require to add a (random) seed to the data in order not the same hash on the network twice.

Sebastians idea of using the offchain-db-adapter to cache the data only temporarily until the application "fetches" the new data would also be useful in this case. The data would reside in the private data collection only for a short amount of time and would get purged. When I understand the mechanisms correctly, the data is only held in the couchdb of the owner and could thus be erased. One could also use the "blocks-to-live" as some kind of self destruction feature. Even if there is a security issue with unauthorized access to data, this would only affect the temporary data and not the full history.

This is just a thought, i might miss some implications ;)

A good read (just for reference): https://medium.com/@kctheservant/private-data-and-transient-data-in-hyperledger-fabric-46b5258f391e

[informartin]

If I understand your proposal correctly, I think that was one option we discussed before choosing the hybrid approach.

There were some challenges with implicit data collections:

1. There may be a timing issue. If the workflow includes some subsequent interactions with the ledger, other organizations may conclude a business relationship. For instance, if the creation of a signature is directly followed by writing to the partner organization's implicit collection, that would be a hint for all members of the network. In the current solution, the retrieved document will be manually checked by the retrieving party, before the signature is checked.
2. Setting correct endorsement policies becomes more complex, as the transaction writing to Org2's implicit collection should only be endorsed by Org2 to hide the business relationship. Other transactions that, for example, store publicly visible data will require other policies.
3. When we were investigating the reliability of private data collections, some features were not yet available (HLF v2.1). That includes retrieving the history for a key.
4. The feature is HLF-specific, other ledgers may not support such a workflow.

However, I think the approach is quite elegant and the aforementioned challenges may be overcome, so it's worth discussing its applicability.