Re: Private data : issues and problems #fabric #fabric-questions #fabric-dstorage


Yacov
 

> because the actual data is unknown to verifiers/endorsers

Well but you can have the endorsement policy be satisfied by a set of members that they are all in the collection policy.
Furthermore you can also have a custom endorsement policy for each collection.



From:        "Ivan Ch" <acizlan@...>
To:        fabric@...
Date:        02/03/2020 01:32 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Private data : issues and problems #fabric #fabric-questions #fabric-dstorage
Sent by:        fabric@...




I apologize for restarting this old topic, someone sent me a private message so I think the least I can do is to make the problem clear


On Wed, Dec 11, 2019 at 06:51 PM, Gari Singh wrote:
1) hashes on chain cannot be validated by any third party, so they can be used by adversaries to trick honest participants

How does this trick honest participants? When you deploy chaincode, you specify an endorsement policy. Transactions which dod not meet the endorsement policy will be marked as invalid. You need to take a look at the overall transaction flow in Fabric: https://hyperledger-fabric.readthedocs.io/en/release-1.4/txflow.html.
The validation rules for Fabric include:
- check to make sure the block is valid and that it was obtained from the correct orderer as specified in the channel definition
- check to make sure the submitter was allowed to actually submit the transaction (e.g. is allowed to write to the chaincode)
- check that the transaction meets the endorsement policy for the chaincode that was invoked
- perform MVCC check

In the case of private data, the steps are the same. If you are not a member of the collection, even though you do not have the actual data you still follow all of the rules above to validate the transaction (including the MVCC check). Not sure how someone can "trick" anyone if you have a strong endorsement policy (e.g. majority, etc).

This is no different than how private transactions work in Quorum, Besu or even Corda if you choose not to have the notary execute transactions.

The problem is that all the checks you mentioned above are checking something non-verifiable and therefore cannot be used to validate any business logic at all!!! because the actual data is unknown to verifiers/endorsers (who cares about endorsement policy if the endorser doesn't know whatever the heck he is endorsing. block, MVCC, and even transaction sender identity checks got nothing to do with the actual business logic).

of course if the data is in clear text than it would work, because then the endorsers would run the logic inside the chaincode to verify the business logic associated with the transactions being endorsed. Quorum has a host of problems but at least they are exploring crypto/ZKP options like the PoC they did with JPMorgan (to be fair, that was only a PoC, but at least it was a good attempt that fabric's been lacking).

the bottom line is Private data feature does not solve the data privacy problem (or any problem to be honest) but it is given a name and making people believe it does. this is unfortunate because fabric's endorsement architecture is actually a much better platform than anything ethereum to run ZKP cryptos.





Join fabric@lists.hyperledger.org to automatically receive all group messages.