[design] besu privacy preserving transactions

[petermetz]

Description

We've decided to add is as the theoretical/design side of the other besu TX privacy GH issue (which is about the actual implementation)

More context can be heard about this during the discussion we had on today's maintainers' call around minute 25 in the recording.
https://wiki.hyperledger.org/display/cactus/2020-11-05+Meeting+notes

Acceptance Criteria

1. The privacy preserving properties are defined for Cactus while interacting with besu ledgers that have privacy features enabled

cc: @hartm @RafaelAPB

[petermetz]

@hartm I don't know Avradip's GitHub username, please tag him as well if you do!

[RafaelAPB]

After reading your comments on #352,

I believe the first step is to clearly and rigorously define what is a connector and validator, and if they support some notion of privacy (e.g., connectors from Cactus nodes do not record transaction parameters, e.g., the connector only connects to a blockchain, and nowhere else ). Based on that I believe the rest depends on composing privacy based on the underlying blockchains, which would depend a lot on every case. And I think this will not be easy, as we only have informal definitions for privacy, e.g.: https://besu.hyperledger.org/en/stable/Concepts/Privacy/Private-Transactions/

It looks to me that a private transaction in Besu is a transaction sent to a group of nodes (privacy group) that hold a separate private state. If this means that only these nodes can access the private state, then Cactus does not necessarily violate the necessary privacy in this case. But what if it fetches the transaction parameters, for instance?

We can further discuss next Thursday at the Western Hemisphere meeting.

[RafaelAPB]

@hartm The privacy model of Cactus should probably follow a minimum common base - and that's what is interesting to find; apart from that my intuition is that it would be useful for Cactus to adapt to the underlying privacy requirements of the underlying blockchains on the go. So if we are dealing with private transactions on Fabric and private transactions on Besu, we want to accommodate the necessary changes to that specific transaction

[hartm]

@RafaelAPB What worries me is that the minimum common base of private transactions across different ledgers might be very small. We need to make sure that there is, in fact, some common ground. This could be difficult if various blockchains have poorly stated or not so good notions of privacy.

It might be useful to start by stating some common privacy definitions and working with those. This would follow your "minimum common base" approach. What do you think?

[petermetz]

Meeting notes are here: https://wiki.hyperledger.org/display/cactus/2020-11-12+Meeting+notes
The last 25 minutes of the recording contains the relevant discussions on this topic.

[ruzell22]

Upon reading the comments on #367 and the related ticket #352, watching the November 5 and 12 2020 recorded meeting, reading besu hyperledger documentation regarding privacy, and testing and looking in the code of privacy-deploy-contract-from-json-cactus.test.ts file, I have summarized the privacy definition that is besu related.

Besu implements restricted private transaction only, thus, only the nodes participating in the transaction receive and store the payload of the private transaction. Gas is not required in private transactions. Ensure that the network has a mechanism to establish trust offchain. Upon the test with private-deploy-contract-from-json-cactus.test.ts , it has been tested when a member is trusted or not and if they can see or access the name and output in the private transactions. (e.g. member1 privately transacted with member2 and they are together in a group, member3 is not part of the trusted member. Member3 cannot see the name, key, or the output even if they request it).

Aside from Besu using restricted private transactions which means only the nodes participating in the transaction can receive and store the payload of the private transaction, it uses privateFrom and privateFor privacy to control which specific member can only access the key and the content of the transaction. All the test cases passed on the said file.

[ruzell22]

@petermetz @jagpreetsinghsasan here is the summarized definition of privacy for besu private transaction. Is there anything that needs to be done further for this ticket based on it? Thank you.

[petermetz]

@petermetz @jagpreetsinghsasan here is the summarized definition of privacy for besu private transaction. Is there anything that needs to be done further for this ticket based on it? Thank you.

@ruzell22 Nothing that we can do as of right now, thank you.