feat(besu): private transaction support

[petermetz]

Depends on #367

Is your feature request related to a problem? Please describe.

Feature request: I need to be able to issue private transactions to a Besu ledger via the Cactus API client.

Describe the solution you'd like

1. Either a separate endpoint next to the current POST /run-transaction one or as an extension of it. Not yet sure which one is more feasible/makes more sense.
2. Test coverage for the new feature
3. Private transactions must not be logged by Cactus for obvious reasons.

Describe alternatives you've considered

Nothing. There is no doubt in my mind that we need this feature.

Additional context

Here's the Besu documentation regarding private transactions: https://besu.hyperledger.org/en/stable/Concepts/Privacy/Private-Transactions/

cc: @takeutak @sfuji822 @jonathan-m-hamilton

[hartm]

It looks like we're going to want private transactions across a lot of different frameworks. I think this is going to require a considerable amount of analysis to make sure we get the security properties around each private transaction correct.

Do you know of a good resource where we can find what the exact definition of privacy that these transactions on these blockchains are claiming (for Besu, obviously, but also Quorum and any other systems you want to add privacy)? Some of these privacy definitions might not even be compatible with each other, so we need to be careful.

@RafaelAPB

[petermetz]

Some of these privacy definitions might not even be compatible with each other, so we need to be careful.

@hartm Agreed. For now we don't have a unified transaction execution API defined/enforced for the connector plugins. Each plugin defines it's own API interface (OpenAPI specs) from the ground up for transaction execution. The reasoning behind this is just that it seemed impossible to take everything into account up-front without having implemented the basics first separately for each. This of course leads to a little bit of repetition between the quorum and the besu connectors code because they are both (for now) just glorified Web3 wrappers, but I expect this to turn into an advantage as the development of more exotic features such as TX privacy progresses.

[hartm]

@petermetz My point is not about the API interface--it's about the (theoretical in nature) privacy guarantees. These are stated in terms of "privacy definitions."

Privacy doesn't compose well. It's possible that two systems that are independently "private" have no privacy when both are used. So we have to be careful in terms of what we can guarantee: two systems might have incompatible notions of privacy, for instance.

Does this make sense?

[petermetz]

@petermetz My point is not about the API interface--it's about the (theoretical in nature) privacy guarantees. These are stated in terms of "privacy definitions."

Privacy doesn't compose well. It's possible that two systems that are independently "private" have no privacy when both are used. So we have to be careful in terms of what we can guarantee: two systems might have incompatible notions of privacy, for instance.

Does this make sense?

@hartm Makes sense. We are in agreement.

[hartm]

@petermetz

I guess what I'm saying is this is where we will want formal guarantees of privacy. We can ask some of the academics like Rafael and Benedikt to help us with this.

[petermetz]

@petermetz

I guess what I'm saying is this is where we will want formal guarantees of privacy. We can ask some of the academics like Rafael and Benedikt to help us with this.

@hartm Agreed, help on the formal definitions is very welcome especially because personally, I'm much more comfortable/versed in the trenches of implementation. (most likely why I also thought/assumed that that's what you were talking about initially, thank your past and future patience on that front! :-) )

[RafaelAPB]

From an implementation perspective: I was trying to implement the functionality of issuing private transactions on the connector, but I faced some issues. I talked to a Besu's maintainer some time ago: https://github.com/hyperledger/besu/issues/504, and it looks like that " private equivalent of https://web3js.readthedocs.io/en/v1.2.0/web3-eth-contract.html hasn't been implemented yet", so probably some workarounds are needed.

I'll answer on #367 regarding design

[petermetz]

Closing this because we've added support a while back[1]. I'll keep the other one [2] open which is about design as due diligence.

[1] packages/cactus-plugin-ledger-connector-besu/src/test/typescript/integration/plugin-ledger-connector-besu/deploy-contract/private-deploy-contract-from-json-cactus.test.ts [2] https://github.com/hyperledger/cacti/issues/367