No-Random Feature

[illuzen]

This PR adds a feature to both plonky2_field and plonky2 subcrates called "no_random", which removes any randomness from the library. This is ideal in use-cases where the verifier is on a blockchain. In our case, substrate's build process itself will not allow randomness. Of course disabling randomness requires disabling many tests and significantly impacts the prover side of things, but the feature is designed for verifiers.

This PR addresses this issue: #1659

The general strategy was to gut the Sample trait, but leave it defined, then put everything that uses those functions behind cfg flags. There were a couple other places that deserve mention, I will point them out in the code.

Probably many of these tests could be salvaged by using the hash of some default value or something but it didn't seem worth doing.

[illuzen]

This was a little awkward, but we are just asserting false if someone sets zero-knowledge to true and no-random to true, since the field is not so easy to put behind a feature flag.

[illuzen]

I can address these CI issues, but could someone comment on whether this is something you guys find useful?

[Nashtare]

I can address these CI issues, but could someone comment on whether this is something you guys find useful?

Overall I'm not sure the approach taken is ideal, it's bloating the codebase and mixes up std with the not(no-random) feature while it seems (unless I am missing something) that you would never need to use std and no-random at the same time?

[illuzen]

Yes it is a little awkward, there's probably a better way to organize the features. TBH, I don't 100% understand why this worked, we just arrived at it by a process of elimination on the dependencies.

[target.'cfg(all(target_arch = "wasm32", target_os = "unknown"))'.dependencies]
getrandom = { version = "0.2", default-features = false, features = ["js"] }

this for instance was causing issues for us, even tho it seems like it was trying to address the sort of problem we have.

std/no-std doesn't fully articulate the issue either. Open to suggestions here, or we can just use our own fork of this, but we'd rather be able to easily update as you guys release improvements.

[illuzen]

I can address these CI issues, but could someone comment on whether this is something you guys find useful?

Overall I'm not sure the approach taken is ideal, it's bloating the codebase and mixes up std with the not(no-random) feature while it seems (unless I am missing something) that you would never need to use std and no-random at the same time?

@Nashtare that's true, but there's some possibility to use neither as well, so it doesn't really make sense to merge no-random into a no-std feature. For example an embedded device might want to compile to wasm but use randomness.

Is there some version of this PR that you would merge? I'm happy to refactor to make it less of a bloat if you have suggestions.