Make return values distinct by default

[Savio-Sou]

Problem

Return values of Noir programs currently require opt-in to be made distinct.

Albeit not-distinct could yield less constraint counts for certain programs, the way it optimizes and reorders the witness during compilation isn't necessary intuitive for developers to comprehend versus how public inputs and return values are defined in their Noir programs / Verifier.toml.

This in turn leads to potential confusions and footguns with how public values are generated and serialized, and by extension how to use them with proofs for verification.

For example:

• Nargo: Nargo fails to verify the proof (repro attached) #4443 (comment)

• Solidity verifier:

  From @sirasistant:

  For example, with this code:

  fn main(a: Field) -> pub (Field, Field) {
   (a + 1, a)
  }

  If you follow the instructions here https://noir-lang.org/docs/how_to/how-to-solidity-verifier/
  And you deploy a verifier, it'll require building your public inputs knowing how the compiler organized the return witnesses!
  So if you do nargo prove with a=1, if you try to do solidity verification with [2,1] as you'd expect (by taking the return values from Verifier.toml) it'll fail, you need to swap the order

Happy Case

Make the existing distinct behavior the default and remove the keyword.

Project Impact

None

Impact Context

No response

Workaround

None

Workaround Description

No response

Additional Context

Credit to @PhilWindle for flagging the footgun.

I don't personally know how much of a performance gain does not-distinct give, hence if it's justified to come up with a new keyword for developers to opt into that.

Insights welcome below.

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[Savio-Sou]

@TomAFrench mentioned we already have an abi-decoding tool; a better approach might actually be documenting and bringing awareness to the tool.

@TomAFrench to investigate.

[sirasistant]

Using abi encoding and decoding in nargo/JS is fine, but in solidity and recursive circuits this problem is unsolved I think.

In solidity and recursive circuits I think devs want to treat the circuit public inputs as structured data to make some checks on it, and then transform it into the public inputs vector for verification of the circuit. I think we'd need a solidity "noir ABI" encoder and a noir "noir ABI" encoder which adds a lot of complexity vs just serializing the data structure to an array of fields.

[TomAFrench]

Agreed, I've been doing some thinking as well on the recursion issue and come to the same conclusion. Between that and a couple of other issues related to return witnesses, it's time make this the default.

There's some optimisations we can perform the avoid the constraints just to renumber the witnesses into the correct order but fundamentally we should be discouraging users from excessive returns from their programs where it can be shown that they're unnecessary.