Private & public return values

[sirasistant]

Problem

Currently, we only support public return values:

fn main(var: Field) -> pub (Field, Field) {
    (var * 2, var + 1)
}

However, there are some usecases for being able to mix public and private return values:

• Computed data for the prover avoiding code duplication on the prover side to compute data that the circuit is already computing
• Packing return values: if # of public inputs is expensive or like in the aztec case the functions are sandboxes and have to follow a strict public inputs shape, you can only expose publicly a hash and return the preimages as a private input. If it's a regular circuit you'd send the preimages along with the proof and public inputs to the verifier.

Happy Case

Having syntax like this available:

fn main(var: Field) -> Field, pub Field {
    (var * 2, var + 1)
}

Or like this

fn main(var: Field) -> (Field, pub Field) {
    (var * 2, var + 1)
}

Visibility modifiers would only have meaning on main. Only the witnesses of the public members of the return values of main would be public inputs to the circuit (along with the witnesses of the public arguments of main).

This will require changes to the frontend (parser) and the backend (Circuit struct now needs a split of private and public returns) and a breaking change of the ABI (right now only one return type can be there, with one possible visibility)

Project Impact

This is necessary for variable-sized (different return sizes for different functions) return values in aztec functions. Since they are verified by the kernel, they have to follow a strict shape for the public inputs, so variable-sized returns aren't possible currently. This will allow to only have the hash of the return values in public inputs.

Impact Context

Workaround

Yes

Workaround Description

A workaround would be possible leveraging oracles (an oracle providing the private return value could be called at the end), but the shape of the oracle parameters wouldn't appear in the ABI so it'd be a very limited workaround

Additional Context

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response