[Fix] Make deployment verification consistent by deterministically seeding the RNG.

[d0cd]

This PR:

• fixes deployment verification by deterministically seeding the RNG.

Failing Case

This issue was found in a deployed program with a similar structure to:

program test.aleo;
function foo:
    input r0 as field.private;
    cast r0 into r1 as scalar;

At a high-level, deployments are verified by randomly generating inputs, executing the program, extracting the assignment, and checking that the associated certificates match the structure of the assignment. Note that the actual values do not matter. Source

The core issue is that RNG used in generating random inputs can differ across different runs of verify_deployment.

The failing case manifests in the following way:

• The execution of cast r0 into r1 as scalar; creates an invalid scalar field element when r0 is larger than the scalar field modulus.
• The resulting value is ejected before storing the result into the register r1.
• Scalar::eject_value halts, if the scalar field element is invalid.
  Consequently, a deployment of the above program can fail to verify depending on the random inputs that were used.

Solution

To fix this issue, this PR deterministically seeds the RNG used in deployment verification with the lower 64 bits of the deployment ID. This ensures that validators will use the same seed for a particular deployment, which ensures that they will always agree on whether the deployment is valid or not.

Testing

This PR includes a test that attempts to deploy a program that loads and stores data types with invalid scalar field elements. The test verifies that the status of the deployment is consistent: always valid or always invalid, independent of the RNG.

CI for this branch is running here.

Considerations

In addition to this PR, additional mitigations can be put in place to ensure that:

• Scalar::eject_value does not halt
• Loading and storing circuits to registers does not invoke eject_value. This is dependent on whether or not the invocations of eject_value are intended to serve as a value check or a less strict type check.

Related PRs

Use this PR over #2534

[MaximizeYourGPU]

Test rev

[vicsn]

I would recommend to not use the rng argument at all within verify_deployment. The existing assumptions which this PR makes also applies to the burner_private_key: its value is not important and if god forbid there's a bug in the key generation code then we'd rather want all validators to abort equally.

That being said, this recommendation is not essential, so if we're in a time crunch, we can also leave it for later. In a future PR, we can also consider removing the rng argument in check_next_block entirely to prevent future developers from introducing non-determinism.

[zkxuerb]

LGTM

[evanmarshall]

[lukenewman]

🫡

[raychu86]

Added a tweak to minimize change-set and clean up the testing; the logic should be equivalent.

Unfortunately this dismissed the previous reviews.

[aleojohn]

LGTM