Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the underlying reproducible random impls instead of StdRng. #7717

Merged
merged 5 commits into from
Sep 28, 2022

Conversation

robin-near
Copy link
Contributor

@robin-near robin-near commented Sep 28, 2022

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.

@robin-near robin-near requested a review from a team as a code owner September 28, 2022 21:19
chain/chain/src/chain.rs Outdated Show resolved Hide resolved
chain/epoch-manager/src/proposals.rs Outdated Show resolved Hide resolved
@mzhangmzz
Copy link
Contributor

Thank you for the fix!

@robin-near robin-near merged commit a10b5d7 into near:master Sep 28, 2022
@robin-near
Copy link
Contributor Author

Thanks for the additional fixes @mina86 !

nikurt pushed a commit that referenced this pull request Sep 29, 2022
* 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);
Copy link
Contributor

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.

nikurt pushed a commit that referenced this pull request Nov 9, 2022
* Use the underlying reproducible random impls.

* Improve testing

* fix deny

* fmt

Co-authored-by: Michal Nazarewicz <mina86@mina86.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants