Consistent naming across different implementations

[0xbok]

Same values are named differently across implementations. While it's not a big deal for small code size, it helps the reader if they can be named same throughout.

For example: h[m,pk]^r is called:

• z in arkworks impl,
• hash_m_pk_pow_r in k-256 impl,
• hashMPkPowR in js and
• h_pow_r in circom

Differing upto casing is fine, but arkworks impl variable name deviates the most from others.

[skaunov]

I'll groom things, though particular examples which absolutely require attention would be beneficial.

[skaunov]

I guess it's best to choose naming based on the blog post, paper, and then some best judgement / linting?

[Divide-By-0]

I guess it's best to choose naming based on the blog post, paper, and then some best judgement / linting?

That seems great. Also we can make edits to the blog post to include that terminology :p

https://github.com/Divide-By-0/blog/blob/main/content/posts/nullifier.md

[skaunov]

That seems great. Also we can make edits to the blog post to include that terminology :p

https://github.com/Divide-By-0/blog/blob/main/content/posts/nullifier.md

I can share my own experience: when first exposed to the scheme/protocol this hash & hash2 thing isn't make it really easier to follow. Do you think they could be more semantic?

[Divide-By-0]

That seems great. Also we can make edits to the blog post to include that terminology :p
https://github.com/Divide-By-0/blog/blob/main/content/posts/nullifier.md

I can share my own experience: when first exposed to the scheme/protocol this hash & hash2 thing isn't make it really easier to follow. Do you think they could be more semantic?

perfect! you should be able to fork slides.plume.run and the md blog post to be consistent with the semantic changes you made here, if you think it would help. im also now wondering if docs would be helpful!