-
Notifications
You must be signed in to change notification settings - Fork 686
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Use the underlying reproducible random impls instead of StdRng. #7717
Conversation
Thank you for the fix! |
Thanks for the additional fixes @mina86 ! |
* Use the underlying reproducible random impls. * Improve testing * fix deny * fmt Co-authored-by: Michal Nazarewicz <mina86@mina86.com>
|
||
fn shuffle_duplicate_proposals(dup_proposals: &mut Vec<u64>, rng_seed: RngSeed) { | ||
let mut rng: Hc128Rng = SeedableRng::from_seed(rng_seed); | ||
dup_proposals.shuffle(&mut rng); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing I am worried here is that the specific shuffling algorithm that rand
is using is unspecified. So in theory upgrading rand
might change the result here.
If we are replacing protocol_defining_rand with a fixed rng (which is ❤️ ), I'd sleep better if we also vendored our own knuth_shuffle
, so that we avoid problems a-la rust-lang/rust#85773.
We have tests here, so they'll probably catch drastic changes in the algorithm, but if it is something more subtle (like, use some super-advanced simd on specific CPUs or whatever), we might miss it.
* Use the underlying reproducible random impls. * Improve testing * fix deny * fmt Co-authored-by: Michal Nazarewicz <mina86@mina86.com>
StdRng isn’t reproducible. As recommended by the comment on top of
StdRng, use the underlying specific algorithms. For proposals this is
Hc128 (what StdRng uses at rand=0.6.5), and for receipt shuffling this
is ChaCha20 (what StdRng uses at rand=0.7).
Added two unit tests to sanity check that the underlying impl does not
change. I've manually checked with similar testing using the
appropriate version of StdRng that the results do match what we
would've produced before this change.