You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there a reason for using the traits VDFParams and VDF over inherent methods? There are clear reasons to be generic over the group implementation, and ideally this should even be exposed, but afaik there is never any reason to being generic over the proof type.
The text was updated successfully, but these errors were encountered:
They do offer the same API, with the same semantics, so doesn't it make sense to make them implement the same trait, in case someone wants to make the VDF algorithm configurable?
I suppose but traits can hide more than desired too.
Just another idea: Avoid the separate params types and traits by making the params public in the VDF types, because the separate params types and traits seemingly do nothing. Also, expose the real functionality as inherent methods for the VDF types. If users want to change anything else, then they can reimplement VDF for some wrapper type with different parameters. At present, there are no other parameters, but the obvious ones include the group and some ownership function.
Is there a reason for using the traits VDFParams and VDF over inherent methods? There are clear reasons to be generic over the group implementation, and ideally this should even be exposed, but afaik there is never any reason to being generic over the proof type.
The text was updated successfully, but these errors were encountered: