Commitment-scheme without salt

[donosonaumczuk]

Avoid a salt on the commit preserving the security properties. This will require jurors to only remember the choice when calling castVote without the additional random salt, highly improving the UX.

This is achieved by using EIP-712 signatures, I realized this and developed this commitment-scheme for my master thesis' protocol, which was a decentralized news platforms that uses dispute resolutions. Here you can see the commit and reveal implementations of my thesis proof of concept. I will provide more details later as I need to translate that section of the technical paper, and will come up also with the PR.

Note: If you check the PoC code I pointed to, the nonce is not a salt, is just a sequential number used to prevent commits being the same when using the same choice. So jurors can override the commit multiple times and each commit will look different, to avoid external observers to find patterns.

[shotaronowhere]

Actually the salt is already deterministically produced with EIP-712 signatures, so the user does not currently need to 'remember' their salt.

check the couple comments on derived accounts here
https://blog.kleros.io/kleros-athena-release-built-on-trees-hooks-and-derived-accounts/

I like your thinking with using EIP-712 signatures, but ecrecover costs an extra 3k gas to validate signatures which would make revealing votes more expensive.

We are thinking about using Shutter Network in v2 for commit-reveal.

https://blog.shutter.network/announcing-shutter-governance-shielded-voting-for-daos/

page 39, second bullet point of the yellow paper also alludes to the possibility of using Shutter Network for threshold encryption

https://kleros.io/yellowpaper.pdf

[jaybuidl]

Good thinking indeed. If we are not going to consider ecrecover at all due to cost (even though we are on a rollup), then we can close the issue @shotaronowhere .

[shotaronowhere]

Well maybe @donosonaumczuk can elaborate, but it's just that why not use the signature off chain to deterministically produce the salt, and use the commit reveal scheme with just keccack256 hashing. I don't see the benefit of validating the signature on-chain. It would be just unnecessary. Not simply cost prohibitive, just not needed. This is the approach we already take, here's our salt generation for vote commitment.

We just do this off-chain, and keep on-chain contracts minimal.

[donosonaumczuk]

Interesting, I didn't know the salt was generated from a signature. So your current scheme is following the UX standards I was proposing, perfect!

---

I don't see the benefit of validating the signature on-chain.

Doing the ercrecover and checking the signature validity is useful for standarizing the salt and ensuring some level of security for all of them. However, you can argue that you prefer gas cost over standarized-secured salt, which I would perfectly understand.

---

Thanks for taking the time replying!