In order to be able to associate requested spends and outputs with the
indices of the actions that execute these operations, it is necessary to
track the randomization of inputs and outputs and return the mappings
that resulted from that shuffling.
This adds a flag to `BundleType` that, when set, requires a dummy-only
bundle to be produced even if no spends or outputs are added to the
builder, and when unset results in standard padding.
The term `recipient` is commonly used to refer to the address to which a
note is sent; however, a bundle may include multiple outputs to the same
recipient. This change is intended to clarify this usage.
Co-authored-by: Daira Emma Hopwood <daira@jacaranda.org>
to 10240. This improves the accuracy by ensuring a more even distribution
of more expensive decryptions.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
The benchmark assumed that the first action in the bundle was for the
recipient it had added, but we've started shuffling recipients within
actions, and the builder pads to a minimum of two actions. This meant
that 50% of benchmark runs would fail to start, but would proceed fine
if they did start (as the bundle is cached for the entire test).
We now add two recipients, to cancel out the effect of the padding and
shuffle.
For almost all the sponge constructions defined in the Poseidon paper,
the domain can be defined completely statically. Variable-length hashing
requires knowledge of the message length, but that can be provided to
the fixed padding function in a subsequent commit, and in any case we
can't use variable-length inputs in a circuit.
Criterion's benchmark grouping does not match on group names; it only
groups benchmarks that are run prior to that specific benchmark group
instance being dropped. Since each benchmark group holds a mutable
reference to the criterion instance, this means we can't have multiple
active groups collecting measurements. Instead, we need to collect the
proving benchmarks for all recipient numbers, followed by verification
benchmarks.
As the underlying `Region` methods now return `AssignedCell` instead of
`Cell`, we can simplify all the places where we then constructed a
`CellValue` struct.
We change `CellValue` into a typedef of `AssignedCell` to simplify the
migration in this commit.
The migration from `CellValue` to `AssignedCell` requires several other
changes:
- `<CellValue as Var>::value()` returned `Option<F>`, whereas
`AssignedCell::<F, F>::value()` returns `Option<&F>`. This means we
need to dereference, use `Option::cloned`, or alter functions to take
`&F` arguments.
- `StateWord` in the Poseidon chip has been changed to a newtype around
`AssignedCell` (the chip was written before `CellValue` existed).
Kris Nuttycombe
Daira Hopwood
Jack Grigg
therealyingtong
Jack Grigg