Cannot query encrypted KeyValueDatabase examples

[LucasG0]

Hi, I tried to run encrypted KeyValueDatabase and I got some issues while querying both static-size and dynamic-size databases. I simply installed concrete using PyPi then copied/pasted/ran examples source code. I am just starting using concrete, so apologies if I missed something.

Here is the output I got for static-size.py:

/home/lucas/venvs/concrete/bin/python3.10 /home/lucas/open_source/concrete/static-size.py

Compiling insertion circuit...
(took 0.278 seconds)

Compiling replacement circuit...
(took 0.248 seconds)

Compiling query circuit...
(took 0.160 seconds)

Generating insertion keys...
(took 0.095 seconds)

Generating replacement keys...
(took 0.097 seconds)

Generating query keys...
(took 0.057 seconds)

Inserting...
(took 1.010 seconds)

Querying...
Traceback (most recent call last):
  File "/home/lucas/open_source/concrete/static-size.py", line 245, in <module>
    assert db.query(3) == 4
AssertionError
(took 0.217 seconds)

Process finished with exit code 1

and here is the output I got for dynamic-size.py:

/home/lucas/venvs/concrete/bin/python3.10 /home/lucas/open_source/concrete/db_dynamic_size.py

Compiling replacement circuit...
(took 0.549 seconds)

Compiling query circuit...
(took 0.402 seconds)

Generating replacement keys...
(took 0.133 seconds)

Generating query keys...
(took 0.140 seconds)

Inserting...
(took 0.000 seconds)

Querying...
Traceback (most recent call last):
  File "/home/lucas/open_source/concrete/db_dynamic_size.py", line 206, in <module>
    assert db.query(3) == 4
  File "/home/lucas/open_source/concrete/db_dynamic_size.py", line 187, in query
    accumulation += self._query_circuit.encrypt_run_decrypt(encoded_key, *entry)
numpy.core._exceptions.UFuncTypeError: Cannot cast ufunc 'add' output from dtype('float64') to dtype('uint64') with casting rule 'same_kind'

Process finished with exit code 1

[umut-sahin]

Hey @LucasG0, you were right. It seems the recent changes made to some operations resulted in this problem.

The core of the issue comes from == now being multi precision by default. What this means is it'll result in an actual 1-bit value. We have operations like these in the implementation:

np.sum((candidate_key - key) == 0) == NUMBER_OF_KEY_CHUNKS

The problem was the inputset was not sufficient, and it resulted in np.sum((candidate_key - key) == 0) to be assigned a very low bit-width during compilation. However, in runtime, the keys were the same so this value overflowed!

The solution is to hint these intermediates to indicate what can be the result of them in the worst case for bit width.

PR is open, and it'll be fixed soon.
Let us know if you have more questions!

[LucasG0]

Alright, thanks for the explanation!