Consensys / quorum

A permissioned implementation of Ethereum supporting data privacy
https://www.goquorum.com/
GNU Lesser General Public License v3.0
4.69k stars 1.3k forks source link

Easier way to keep track of privateFor arrays for a contract #110

Closed paliwalg closed 2 years ago

paliwalg commented 7 years ago

System information

Geth version: geth version

OS & Version: Windows/Linux/OSX

Branch, Commit Hash or Release: git status

Expected behaviour

Actual behaviour

Steps to reproduce the behaviour

I have deployed the simpleStorage smart contract from node 1 as a private to node 7. Now to perform the private transaction (set() function) as per the documentation I have to specify the privateFor.

If I don't specify the privateFor while calling set(), it gives error invalid address value. Since the contract is deployed privately, the private transactions should also take the privateFor the same way if I don't specify the privateFor for the private transaction that is set() call should default to private transaction to node 7. Is this possible ? If not how can I achieve it ?

Thanks

Backtrace

[backtrace]
patrickmn commented 7 years ago

You currently have to specify your recipients for each transaction, whether it's a contract creation or operation against a contract. Part of the reason why is that the presence of the privateFor array is what indicates that this is a private transaction.

patrickmn commented 7 years ago

I'll reopen/change to a feature request. It would be nice to have, but would also require quite a lot of work (since without privateFor it's not clear if it's private, and we're not keeping track of what keys were party to which transaction or contract.)

I suggest tracking participants with a hashmap from contract address to array of public keys for now.

paliwalg commented 7 years ago

Thanks Patrick,

This feature will really help, and with this feature I don’t have to share the public keys with all the party.

Our scenarios is that I have a moderator node which deploys the contract for each participant privately specifying their public key in privateFor. Being a moderator I am good with moderator knowing the public keys for each participant. Now each participant can invoke the methods on the deployed contract specifying the public key of moderator. I wanted to get rid of moderator explicitly publishing its public key to each participant. I just wanted to invoke the method of the private contract without specifying privateFor. Since it’s a private contract between moderator and a participant, this call should get default as a private call with moderator in absence of privateFor. It can’t be considered as public since public transaction are not allowed from a private transaction.

Thanks -Gourav

From: Patrick Mylund Nielsen [mailto:notifications@github.com] Sent: Monday, May 1, 2017 11:08 PM To: jpmorganchase/quorum quorum@noreply.github.com Cc: Gourav Paliwal Gourav.Paliwal@synechron.com; Author author@noreply.github.com Subject: Re: [jpmorganchase/quorum] Query : Private Transaction (#110)

I'll reopen/change to a feature request. It would be nice to have, but would also require quite a lot of work (since without privateFor it's not clear if it's private, and we're not keeping track of what keys were party to which transaction or contract.)

I suggest tracking participants with a hashmap from contract address to array of public keys for now.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/jpmorganchase/quorum/issues/110#issuecomment-298382902, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMKwX95DgBR90OKJBj9S8OJqxhQ3dSYWks5r1hhtgaJpZM4NNOQo.

antonydenyer commented 2 years ago

Since this was raised several enhancements have been added around privacy. I believe they enforce what you are looking for. Although you will need to share the moderator public key if the participant makes a mistake it will prevent the transaction from being executed.

https://consensys.net/docs/goquorum//en/latest/concepts/privacy/privacy-enhancements/

From an implementation point of view, there is no way to keep the public key secret from the participant, they would still need to know it inside their enclave.

The way hyperldger/besu implements privacy groups may be closer to what you are looking for. But even then, the group id is just an alias for a collection of public keys.