Expose Databus objects to the backend

[guipublic]

Problem

Aztec kernel circuits require a lot of input/output data, and in order to avoir to increase the size of the circuit too much because of many public inputs, we want to leverage the ‘databus’ concept.
The idea is to commit to the data and have the proving system to check that commitments match (intput to circuit i is output of cicruit i-1, etc..)
In Barretenberg, the databus will be similar to a ROM table, with methods to set the values and read them at the provided index.

Here is an example where calldata (inputs) is [4,5,6,7,8], and return_data (output) is [4,5,6,13], i.e. the output is identical to the input but with the last two entries summed together.
This can be proven with the following relation:

// First three entries are simply 'copied' from input to output
databus.calldata[idx_0].assert_equal(databus.return_data[idx_0]);
databus.calldata[idx_1].assert_equal(databus.return_data[idx_1]);
databus.calldata[idx_2].assert_equal(databus.return_data[idx_2]);

// Final output is the sum of the last two inputs
field_ct sum = databus.calldata[idx_3] + databus.calldata[idx_4];
sum.assert_equal(databus.calldata[idx_final]);

Happy Case

In Noir, we already handle call_data and return_data attributes in the main function and we aggregate such parameters into one array (one for call_data and one for return_data).

What we need to do to integrate with Barrentenberg:

• create new opcodes to access and initialise the databus call_data / return_data.
• replace array init with databus initialisation
• replace ‘array get of the call_data array’ with a ‘databus opcode’
• make return_data private input
• Assert the return data is equal to databus return_data

Project Impact

None

Impact Context

No response

Workaround

None

Workaround Description

No response

Additional Context

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[TomAFrench]

For reference: https://hackmd.io/pTE38VziRP-rMBDrOnbweQ?both