Make domain size configurable

[georgepisaltu]

Changes in this PR:

• Replace the compile-time small-ring feature flag with runtime-configurable RingDomainSize enum supporting three domain sizes:
  • 11: max 255 members
  • 12: max 767 members (new domain with params added)
  • 16: max 16,127 members
  • Add DomainSize type with trait to GenerateVerifiable allowing domain_size to be passed to start_members(), open(), validate()
  • Make ring builder params that bloat library binary size feature gated behind builder-params.
  • Add generate-keys feature to gate the rand dependency used in the --bin compilation to generate keys.
  • Add test_for_all_domains! macro to run ring VRF tests against all domain sizes

[ggwpez]

I think it could be enough to just use the spin lock variant of ring_prover_params. I dont think we will have many threads call this during the initialization phase.

[georgepisaltu]

I added a todo to address it in the future.

[ggwpez]

Maybe the opening should also be its own trait and not be implemented for BandersnatchVrfVerifiable unless no-std-prover is provided.
Just to avoid possibly panic paths in the runtime. But can be done in another MR for sure.

[georgepisaltu]

Gated access to the function.

[ggwpez]

Also should maybe be moved into another trait in the future.

[georgepisaltu]

Gated access to the function.

[ggwpez]

Could be put in to a function and use the RingDomainSize::ALL to do it for all sizes.

[georgepisaltu]

Done.

[davxy]

@georgepisaltu @ggwpez

The main concern here is that DomainSize outside the ring implementation doesn't make much sense
(as you correctly wrote: domain size types used in ring operations).
This can instead be confusing, as downstream users may have no knowledge of polynomial commitment schemes or related concepts. These are strictly implementation details of RingProof when it is based on such schemes. From the user's perspective, the only relevant factor is the number of members they are allowed to include.

I suggest removing this trait from this generic module and replacing it with a more appropriate abstraction.

In the GenerateVerifiable trait, you could introduce an associated type such as Capacity, for example:

trait Capacity {
    const fn size(&self) -> usize;
}

(feel free to choose a better name :-) )

With this approach, the ring implementation can use the ark-vrf helper to derive the required PCS size
(ark_vrf::ring::pcs_domain_size(ring_size)), and then select the appropriate static data based on that value.

In the ring implementation you have:

enum RingSize {
    /// Domain size 2^11, max ring size 255
	Small,
	/// Domain size 2^12, max ring size 767
	Mid,
	/// Domain size 2^16, max ring size 16127
	Big,
}

impl Capacity for RingSize {
    const fn size(&self) -> usize {
        match self {
             Small => max_ring_size_from_pcs_domain_size(1 << 11),
             Mid => max_ring_size_from_pcs_domain_size(1 << 12),
             Big => max_ring_size_from_pcs_domain_size(1 << 16),
        }
    }
}

[georgepisaltu]

I removed the exponent function and redefined the trait and type to be Capacity.