Мое (потенциально неправильное) понимание состоит в том, что plaintext_modulus - это не модуль для кодируемого целого числа, а модуль для каждого коэффициента в полиномиальном представлении.
Этоправильный образ мышления при использовании IntegerEncoder.Однако обратите внимание, что при использовании BatchEncoder (PolyCRTBuilder в SEAL 2. *) ситуация совершенно противоположная: каждый слот в векторе открытого текста представляет собой целое число по модулю poly_modulus.
При B = 2 похоже, что эти коэффициенты будут равны 0 или 1. Однако после применения таких операций, как сложение и умножение, это явно не так.Есть ли хороший способ определить хорошую оценку для коэффициентов, чтобы выбрать plaintext_modulus?
Весь смысл IntegerEncoder в том, что свежие кодировки имеют как можно меньшие коэффициенты, задерживая plain_modulus переполнение и позволяет использовать меньшее plain_modulus (подразумевает меньший рост шума).SEAL 2. * имел инструмент автоматического выбора параметров, который выполнял эвристические оценки верхней границы роста шума и коэффициента открытого текста и в основном делал именно то, что вам нужно.К сожалению, эти оценки были выполнены для каждой операции, в результате чего завышенные значения в более ранних операциях взорвались на более поздних этапах вычисления.В результате оценки оказались не очень точными для более простых вычислений, и во многих случаях параметры, предоставленные этим инструментом, были слишком большими.
Чтобы оценить рост коэффициента открытого текста в умножениях, давайте рассмотрим два полинома p (x) и q (x).Очевидно, что произведение будет иметь степень, точно равную deg (p) + deg (q) - эта часть проста.Если | P |обозначает норму бесконечности многочлена P (абсолютное значение наибольшего коэффициента), тогда:
| p * q |<= min {deg (p) +1, deg (q) +1} * | p || q |.</p>
На самом деле, SEAL 2. * здесь немного точнее.Вместо использования степеней, он использует количество ненулевых коэффициентов в этих полиномах.Это имеет большое значение, когда многочлены редки, и в этом случае вклад от перекрестных членов намного меньше, и лучшая оценка равна:
| p * q |<= min {# (non_zero_coeffs (p)), # (non_zero_coeffs (q))} * | p || q |.</p>
Более глубокий анализ роста коэффициентов в IntegerEncoder -подобных кодировщиках сделан в https://eprint.iacr.org/2016/250 Коста и др. , на который вы можете посмотреть.