Open burdges opened 5 years ago
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.
Yes, that makes sense to me. :+1:
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.