There are two fields in the Run_state that are references (int ref and bool ref). It seems like a very dangerous pattern to me. There's two scenarios in the current logic that I'm worried of (as we transition to a Rust struct):
something uses a reference to initialize a field of the state, and later on mutate that reference (which should mutate the state)
something retrieves a reference field from the state and then mutates it later
Let's check to make sure! There are two reference fields: as_prover and next_auxiliary.
As_prover
This one is easy, it always gets initialized to false, and you can't retrieve the reference (only its value). So we can safely remove the reference.
References in
Run_state.tThere are two fields in the Run_state that are references (
int refandbool ref). It seems like a very dangerous pattern to me. There's two scenarios in the current logic that I'm worried of (as we transition to a Rust struct):Let's check to make sure! There are two reference fields:
as_proverandnext_auxiliary.As_prover
This one is easy, it always gets initialized to
false, and you can't retrieve the reference (only its value). So we can safely remove the reference.You can see it in this code change that was not merged but only created to showcase the change: https://github.com/o1-labs/snarky/pull/800/commits/55ae8dab6a5d38a7690170bcfaad0f571a509d3b
Next_auxiliary
The reference can't be retrieved either, as this is the only way to get the value out of it:
Note that the
makefunction also modifies next_auxiliary due to the R1CS trick:So it is actually never used, it is just a way to return the correct value for
next_auxiliaryto the caller.The only real danger here is then if the caller starts mutating this after calling
make.This commit shows that there's no danger there as well: https://github.com/o1-labs/snarky/pull/800/commits/7549ca9e5151bca214e5823dae513298828ea468