Assessment reports>UPA circuits circuitId hash function change>Discussion>Possible optimization in slice_adder_column

Possible optimization in slice_adder_column

For computation of multi-variable length queries in circuits/src/keccak/multivar.rs, a significant part of the logic involves computation of the slice-adder matrix . This matrix has rows and columns. The values of are constants (known during circuit generation). There are also circuit variables . The matrix is now defined as follows:

To make an example, let us consider the case where and we are considering . Then, will satisfy . Should we have and , then the matrix would look as follows:

If we had , then only the first entries with in the above matrix (counting them from the top) would contain , the rest would contain instead.

If instead we have and , then the matrix would look as follows:

In general, the following matrix shows which entries could be either or , depending on what the values of the are, marked by .

Note that various entries are always zero. These come in three types:

  1. Columns to the right

  2. A triangle at the bottom left

  3. A triangle at the top right (but left of the already mentioned columns)

In general, the entries of these three classes can be described as follows:

  1. but not

Note that the following inequalities always hold:

Thus, . We can now show that the three types of entries above must always be zero:

  1. As , the inequality implies .

  2. As , the inequality directly implies .

  3. If , then by definition .

Instead of using constraints to calculate the matrix entries from their definition, it is more efficient to use the constant where the entry must be zero.

This optimization is done in the code for the first two types of entries that are always zero.

For the first type, this is handled by prepare_preimage and add_slice_at_offset as follows: prepare_preimage passes , as max_nonzero_position to add_slice_at_offset, and then add_slice_at_offset never calculates columns from max_nonzero_position forward.

For the second type, this is handled in slice_adder_column. This does not require any additional data; the entries with can directly be filled with the constant zero.

The optimization not yet implemented is the third type. This could be done as follows.

The prepare_preimage could, in addition to , also pass to add_slice_at_offset, which then passes this value further to slice_adder_column, perhaps as an additional argument offset_max. Then those entries for which j > i + offset_max could be set to the constant zero rather than constraining their calculation from the definition.

The amount of constraints saved by this optimization would be similar to the constraints saved by the second optimization.

Zellic © 2025Back to top ↑