Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hard to understand inputs meaning in verify.circom #62

Closed
Eikix opened this issue Apr 23, 2022 · 3 comments
Closed

Hard to understand inputs meaning in verify.circom #62

Eikix opened this issue Apr 23, 2022 · 3 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@Eikix
Copy link

Eikix commented Apr 23, 2022

Hi all:),

First of: Really cool repo and thank you

I'm a beginner in zero-knowledge field, and i'm exploring different signature verification circuits in circom.

Maybe this is a stupid question but i have a hard time fitting vars' names with their definition,

  • msg = the message that was signed
  • R8 and S = both parts of a edd25519 signature

but what are A, PointA and PointR ?

in my mind there was msg, signature, and pubKey so i'm guessing A, PointA and PointR have something to do with pubkeys.

Proposed fix: adding one-lined comments above signal inputs in verify.circom to help readers map var names to actual definition of concepts

@Electron-Labs Electron-Labs deleted a comment from suniljalandhra Apr 24, 2022
@rahulghangas
Copy link

rahulghangas commented Apr 24, 2022

@Eikix I have realized there needs to be better documentation regarding this.

One thing to note, the circom way to pass in byte sequences is not as little-endian/big-endian, but rather from lowest significant bit to most significant bit. We have assumed the same in these circuits.

To clarify on your doubts, A is the public key in binary (LSB to MSB)
PointA is the point representing the public key on the elliptic curve (encoded in base 2^51 for brevity)
PointR is the point representing the R8 value on the elliptic curve (encoded in base 2^51)

Ideally, the algorithm we follow only takes in A and R8 in binary form, and is decompressed to get PointA and PointR respectively. However, decompression is an expensive algorithm to perform in a circuit. On the other hand, compression is cheap and easy to implement. So, we use a nifty little trick to push the onus of providing both on the prover and perform equality checks after compressing the points within the circuit. Ref

You can find all helper functions to change encodings from well-known formats to circuit friendly formats here

I will add comments in the circuit files to address your proposed solution, post which we can close this issue

@rahulghangas rahulghangas self-assigned this Apr 24, 2022
@rahulghangas rahulghangas pinned this issue Apr 24, 2022
@Eikix
Copy link
Author

Eikix commented May 1, 2022

Thank you for your help:) That was very clear

@rahulghangas rahulghangas added the documentation Improvements or additions to documentation label May 5, 2022
@rahulghangas
Copy link

Fixed in commit ba4c2df

@ultrainstinct30 ultrainstinct30 unpinned this issue Nov 16, 2022
@ultrainstinct30 ultrainstinct30 pinned this issue Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants