Currently num_inputs_per_nested_proof is hardcoded, as if it were a constant that can be set freely. The dispatcher contract also allows this to be changed (in-line with a previous approach). In fact, this is a function of the specific hash used for GGPR input hashing (if GGPR is used for nested transactions).
Suggested changes:
It may be possible to further parameterize the circuit in future, and maybe support other configurations such as no GGPR (for the case of aggregating txs for a single app), but num_inputs_per_nested_tx will always be a function of the way this top-level circuit is configured.
Currently
num_inputs_per_nested_proofis hardcoded, as if it were a constant that can be set freely. The dispatcher contract also allows this to be changed (in-line with a previous approach). In fact, this is a function of the specific hash used for GGPR input hashing (if GGPR is used for nested transactions).Suggested changes:
nuum_inputs_per_nested_txa property of theaggregator_circuit, since this determines whether GGPR is used, and with which hash.It may be possible to further parameterize the circuit in future, and maybe support other configurations such as no GGPR (for the case of aggregating txs for a single app), but
num_inputs_per_nested_txwill always be a function of the way this top-level circuit is configured.