DSL: Investigate why tests for ECDSA secp256k1 pass when secp256r1 fails

[kevaundray]

Relevant PR and comment

#582 (comment)

Context

In barretenberg, when building the constraint system, some gadgets require that the witnesses always be valid, this is even when building the circuit for verification.

A consequence of this is that we have what we call dummy_constraints in the DSL which are used by the verifier when building particular gadgets. One of these is ECDSA.

When applying dummy constraints, in the circuit, we compute the dummy constraints for the verifier and then overwrite the verifiers witnesses using assert_equal, so that they now hold valid dummy constraints for ECDSA.

Now since the prover and verifier must have the same circuit, we cannot use assert_equal solely for the verifier. In the case of the prover, they also apply assert_equal, but they overwrite the previous witness values with themselves. ie this is essentially a no-op.

For ECDSA secp256k1 we were not applying this mechanism to the hashed_message, however the circuit was passing, implying that a hashed_message of all zeroes was working. When we added ECDSA secp256r1, the circuit started failing, and after adding the hashed_message to mechanism, secp256r1 started passing.

Solution

• Find out why it's okay to not include the hashed_message for secp256k1, but it fails for secp256r1.
• Fix this so its consistent.

Note: If we modify barretenberg in the future to not need dummy constraints, which is a larger issue outside the scope of this one, then this issue can be closed too.