LWE: add evaluation key type and technique

[ZenithalHourlyRate]

Related to #1057.

I roughly prototyped it from openfhe/pke/keyswitch (BGV/CKKS), yet I do not know if this is accurate for binfhe schemes (CGGI).

Example:

#generator = #polynomial.int_polynomial<1 + x**1024>
#ring = #polynomial.ring<coefficientType = i32, coefficientModulus = 65537 : i32, polynomialModulus=#generator>

#key = #lwe.key<id = "s", size = 1>
#key_mult = #lwe.key<id = "s", size = 1, basis = 2>
#key_rotate = #lwe.key<id = "s", size = 1, rotate = 2>

#keyswitch_bv_base = #lwe.bv_keyswitch_technique<base = 65536, dnum = 0>
#keyswitch_bv = #lwe.bv_keyswitch_technique<base = 0, dnum = 3>
#keyswitch_ghs = #lwe.ghs_keyswitch_technique<extra_modulus=<elements = <65537 : i32>, current = 0>>

!evaluation_key_mult = !lwe.new_lwe_evaluation_key<from_key=#key_mult, to_key=#key, ring=#ring, keyswitch_techniques= #keyswitch_bv, #keyswitch_ghs>
!evaluation_key_rotate = !lwe.new_lwe_evaluation_key<from_key=#key_rotate, to_key=#key, ring=#ring, keyswitch_techniques= #keyswitch_bv_base>

[asraa]

Hey! Sorry for the delay - I'm finally back online for development now.

[asraa]

Thanks for starting this!

I will explore replacing the BGV / CKKS dialects with the new lwe types in a PR EOW

[asraa]

nit: just remove the _technique here and below

[asraa]

Suggested change

	`base` is the radix base used in decomposition of the coefficient modulus
	`base` is the radix base used in the digit decomposition of the coefficient modulus

[asraa]

thank you for considering the RNS variants! I understand it's important to know the dnums so that the type converter knows the type / shape of the key switching key. For the lowering, we'll need the actual RNS moduli, which we'll pull from the RNS modulus of the ring in the keyswitching key, right?

[asraa]

we could implement the type constraint here.

[asraa]

OptionalParameter? (can also update the assembly format for an optional print)

[asraa]

Why is this an array ref parameter? Wouldn't only a sinlgle technique apply to a given key?

[ZenithalHourlyRate]

I intentionally left the HYBRID keyswitching technique as a combination of BV attr and GHS attr, so that we do not have to define another LWE_HYBRIDKeySwitchAttr where all base/dnum/extra_modulus will be included. If we accept such elaboration, then we can define it and here can be a single technique.

[j2kun]

Please take a moment to let me know the current state of this PR. Is it blocked, or obsolete/closeable? If blocked, please briefly say what needs to be done to unblock it.

[ZenithalHourlyRate]

Please take a moment to let me know the current state of this PR. Is it blocked, or obsolete/closeable? If blocked, please briefly say what needs to be done to unblock it.

I was thinking of coming back to this when we are going to do some serious thing for the lwe-to-poly pipeline, but did not get the time.

Also I think this is somewhat related to #1274, namely how should we design a lwe-level interface for eval keys. If we has lwe types and ops describing eval key related stuff, we do not need that relin/rotate op interface.

[j2kun]

There is a Googler who wants to do some 20% project on lowering some schemes to polynomial, so I will ensure he's aware of this work.

[ZenithalHourlyRate]

We may come back to visit this because we have concrete scheme parameter now (#1379). The current LWE type can not model the evaluation key part so we can not get rid of the bgv.schemeParam. In the end we should get these information solely from LWE type.

I'll rebase this.