Increase the number of private reads & writes

[iAmMichaelConnor]

The number of per-function reads/writes is 4. This isn't enough, especially since the library is currently being inefficient with how many read requests, nullifiers, and commitments it creates (see here for the issue that will fix this inefficiency) (a get_note followed by a replace or remove is causing two nullifiers and two new commitments to be created).

Someone testing the Sandbox just ran into MAX_READ_REQUESTS_PER_CALL as a limit, for a very modest function.

Let's assume the "Zac bus" will enable 4096 fields to be passed between circuits (this is a conservative estimate from chatting with Zac last week). We should modify the code to enable this much data to be passed from an app circuit to a kernel circuit (and from a kernel circuit to the next kernel circuit). We can also continue to make use of public inputs. I might suggest (at least for now) we continue to use public inputs for fixed-size data, and we only use the bus for arrays of data (which might vary in size).

Eventually, we'll have multiple sizes of kernel circuit (for various sizes of arrays). Until then, we don't want to simulate 4096 reads (for example) if an app only needs to do 8 reads. So we shouldn't hard-code the sizes of for loops to some upper-bound: ideally all for loops in the simulator would be flexible to only do as much compute as is necessary. (Of course, when we come to write actual circuits, the for loops will need to be rigidly-sized).

We could use std::vector instead of std::array for all circuit arrays (so a dynamic amount of data can be passed around), but that might be a step backwards, if we intend to eventually unify simulated ('native') circuits and proper circuits.

Clearly this might be a fiddly piece of work. As a quick, intermediate solution, could the constants be easily bumped to something like 32 per function and 128 per tx? (We should benchmark kernel & rollup simulation times before making this change and after making this change). If this is "quick" to do (i.e. before the public release), that would be fantastic.

Tagging @dbanks12 @suyash67 @jeanmon for thoughts.

[dbanks12]

Yes, I believe we should be able to bump them to those smaller values as an intermediate solution.

[dbanks12]

Bumping MAX_READ_REQUESTS_PER_CALL to 64 causes wasm out-of-bounds error while generating circuits.js bindings. I will bump only to 32 for now.

[suyash67]

Resolved by #2062