search

SmartTokenLabs / attestation

Paper and implementation of blockchain attestations
MIT License
48 stars 10 forks source link

Add unpredictable number to Solidity code for ZK proofs #184

Open jot2re opened 3 years ago

jot2re commented 3 years ago

The Solidity part of issue #167

See section 2.2.1 in the Token-negotiator report. See Jira issue 291.

jot2re commented 2 years ago

Bump. This issue is still relevant, especially since others are showing interest in our ZK based ideas. @weiwu-zhang can we maybe push this?

oleggrib commented 2 years ago

UN should be signed, validation require more GAS, but if we need it then option2 can suit it (but we have to change UN flow to use ECDSA - https://github.com/TokenScript/attestation/issues/275):

https://github.com/TokenScript/attestation/issues/266#issuecomment-1171059211

but maybe option 1 will be enough? user always will be warned when he share attestation secret and we dont waste gas?

@jot2re , what do you think?

jot2re commented 2 years ago

I am not sure option 1 form #266 is sufficient in this case. It depends on the use-cage. For example if the user needs to prove the same email used in an attestation as in the ticket, then such a proof could be reused. Of course the contract might disallow this, but in general it is not good to share cryptographic proofs on the blockchain which are not linked to a specific usage.

oleggrib commented 2 years ago

@jot2re yes, option 1 solve bit different problem: avoid to share attestation+secret with anyone without confirmation (through hidden iframe)

for UN+ZKP: if we use ZKP for smartContract then context can be a smartContract address, but I am not sure how to do it in gas-efficient and secure way

jot2re commented 2 years ago

I am also thinking something along the line of only using the address. When it comes to the UN on the blockchain, verification would require validating a signature (assuming we change UN implementation), which would be 3000 gas plus everything else. So maybe it makes sense to have a different flow in off-chain and on-chain cases; using UN with optional context in the off-chain setting and simply using a context which is the address in the on-chain setting.

oleggrib commented 2 years ago

@jot2re , in case if we use smartContract address as context then we need definitely different context for off-chain (when we dont have smartContract address), domain can be good and simple option.

currently we check if both secrets fit each one. but how to mix context to this schema?

jot2re commented 2 years ago

@oleggrib it is a good question! I am not sure what the best approach will be for mixing the two different situations