Closed drskalman closed 1 month ago
Some notes that could help during ThinVRF specs writing :
ark-transcript is robust when used in a larger protocol, like here the same transcript could be used for dleq_vrf and ring-proof. We do this because it's cheap and saves us thinking about things later.
Should we add a method which doesn't push the length to implement stuff specd differently (e.g. RFC 9381)?
No.
The only other serious preposal for robust domain speration in hashing is the SAFE API, which works similarly, but optimized for SNARKs. SAFE API produces a single domain seperation constant, but fills your code with panics if any of the lengths are wrong, etc. It's a nice ida for SNARKs, but they've not made it user friendly enough.
BTW ArkTranscript adds word challenge before hashing that is not what RFC9381 calls for.
We should discuss if this should be something else besides the label "challenge", like maybe a 0x0000, but again we want this to be a clean seperation, because then we do not need to think about it again.
In general, RFC9381 is unsuitable for our use cases. If you can reference RFC9381 usefully then great, but you will break things if you start making changes based upon RFC9381.
We do kinda need vrfs_merge + thin_vrf in sassafras btw, because the claim must uniquely link the ticket. The erased key links the ticket, but maybe no longer exists by claim time. We thus need one common VRF pre-output shared between the ring_vrf and the thin_vrf that claims the ticket, and one VRF pre-output that was never before revealed.
Done
Open Points
So that we're all on the same page and we can have a constructive discussion
[x] Scalars encoding
arkworks
encodes big scalars (e.g. points coordinates) in little endian. Is this fine?ark-transcript
encodesu32
(lengths) in big endian. Should be little endian instead? (more akin to SCALE)[x] Using Edwards form vs Weierstrass form
ring-proof
API to take points in Edwards form.[x] (For Sassafras/Safrole) For the "plain VRF" (i.e. not the ring one) should we stick with Thin-VRF or switch to RFC 9381?
[x] If we go with RFC 9381 we need to add associated data to the challenge.
[x] says there is something wrong with computing $k$
[x] If we decide to use Thin-VRF we need to spec it.
[x]
ark-transcript
appends the length after each item is pushed to the transcript.bandersnatch-vrfs
(not to replace thin-vrf, but as an alternative option) then the transcript can be manually created and then fed in one shot toark-transcript
(which also has a constructor taking a byte slice)[x] Hash to field: hashing algorithm (RFC-9380): XMD:Sha512
[x] Map to curve: We need to introduce Elligator2 as soon as ark-ec 0.4.3 is released. Should ship with this
@drskalman @swasilyev @burdges @AlistairStewart @davxy @andresilva