Companion for substrate #14036

[davxy]

Companion for paritytech/substrate#14036

[burdges]

I disagree with renaming VrfTranscript to VrfInput because transcripts are used for thing other than the input.

It's fine to rename some of the variables since they are inputs, but that's not the general situation for the type.

[davxy]

I disagree with renaming VrfTranscript to VrfInput because transcripts are used for thing other than the input.

It's fine to rename some of the variables since they are inputs, but that's not the general situation for the type.

The VrfInput name maybe is not the most technically accurate but has been choosen because wants to represent some kind of (flexible) input to the vrf_sign method and not THE VRF input as you correctly (technically) intend.

From an abstract POV this input can contain (as you mentioned in the substrate PR) other stuff and is specific to the particular vrf.

Indeed in this case VrfInput contains transcript but also extra data.

I don't think that the end user should be interested or be aware of the very technical details (frankly I don't even think that all users know the meaning of a "transcript" and the role it plays in the Fiat-Shamir transform, and probably - at this level - they should not bother).

IMHO they should just have an abstraction to construct "something" to be given to a method to sign and they should be informed which part of this "input type" contributes to the vrf output and which instead just to the proof.

To summarize. IMVHO just Transcript is not the most appropriate because:

• is not just the transcript
• the user probably doesn't care
• doesn't fit well with the generic vrf trait where other vrfs may not use transcripts

BTW, we can also think about other names