Possibility on providing compiler-friendly API

I’m a contributor to google/heir and am currently working on the BGV/CKKS RNS instantiation, including level-manegement op placement and parameter selection

There are three difficulties I’m facing

  • In AUTO (including FIXEDAUTO/FLEXIBLEAUTO/FLEXIBLEAUTOEXT) mode, compiler issued ModReduce operation does nothing, as it is managed by OpenFHE itself. I’m not satisfied with FIXEDMANUAL as it is not GHS variant so we have less modulus candidates.

    Is there a possiblity to add a mode like FIEXIBLEMANUAL so that all the management is done by the compiler. Also, is it possible for OpenFHE to add a mode that it would err out when found mismathing instead of a silent AdjustCiphertext.

  • In the EXT mode, i.e. the compiler has the strategy to mod reduce before the first multiplication and can issue ModReduce for it. However, we would get sub-optimal result as the additional modulus (should be small) for the additional level would be the same as ScalingModSize.

    Is there a possibility to add an API like SetExtraModSize.

  • More generally, the compiler should be able to select all the moduli, and take the responsiblity for noise management/level management. Would OpenFHE expose a more raw API like SetModuliChain so that the compiler can get the most performance out of it.

1 Like

+1. Generally speaking, we have a handful of researchers who are interested in implementing parameter selection passes in our compiler, and it would be very helpful to be able to test those choices via OpenFHE codegen.

Would you be open to providing the ability to set fine-grained parameters (including, e.g., the RNS primes and such) to the degree that it is possible to do so without requiring major changes to OpenFHE’s implementation?

Thank you for your questions: @zenithal and @j2kun. See my answers below.

It is not easy for FLEXIBLE* modes because the precomputed scaling factors are stored in a way where the current scaling factor degree cannot be larger than 2.

Note that one can force a ModReduce even for flexible modes using the Compress method exposed via the CryptoContext.

We could hypothetically add an extra CryptoGen capabilty that would take a custom moduli chain and compute all precomputed parameters. It would certainly be a significant effort (with some scheme-specific logic). Would you need it for all three SIMD schemes, i.e., BGV, BFV, and CKKS? It seems to me that such capability would be mostly beneficial for BGV and CKKS. Would you also need it for BFV? (I am trying to estimate the level effort for such a project.)

Got it, thanks! Will experiment with this API.

Currently HEIR supports BGV and CKKS and AFAIK does not have immediate plan to support BFV.