Lattigo: use DropLevel API for level reduce

[ZenithalHourlyRate]

DropLevel in Lattigo has the implementation:

// DropLevel reduces the level of op0 by levels and returns the result in op0.
// No rescaling is applied during this procedure.
func (eval Evaluator) DropLevel(op0 *rlwe.Ciphertext, levels int) {
	op0.Resize(op0.Degree(), op0.Level()-levels)
}

which is the same as what LattigoEmitter implements.

In the meantime, CKKS has DropLevelNew but BGV does not have one, so the emitter does not use the DropLevelNew API. Will PR Lattigo to try to add this API.

[Pro7ech]

DropLevel in Lattigo has the implementation:

// DropLevel reduces the level of op0 by levels and returns the result in op0.
// No rescaling is applied during this procedure.
func (eval Evaluator) DropLevel(op0 *rlwe.Ciphertext, levels int) {
	op0.Resize(op0.Degree(), op0.Level()-levels)
}

which is the same as what LattigoEmitter implements.

In the meantime, CKKS has DropLevelNew but BGV does not have one, so the emitter does not use the DropLevelNew API. Will PR Lattigo to try to add this API.

@ZenithalHourlyRate I'm curious about which scenario this method would be called. This more an artifact of the early stages of Lattigo than anything else because the evaluator automatically manages the levels of the ciphertexts, so this method never has to be called during circuit evaluation. The one case I can think of is when marshalling the result of a computation when the output ciphertext is not at the minimum level (still the circuit should ensure that), as calling this method can reduce the data sent back to the client. However in this circtumstance it can also be done in place.

[ZenithalHourlyRate]

The MLIR SSA form (we are pinning to value-semantic) could not express inplace operation, so a drop level operation in HEIR would be %new = lattigo.rlwe.drop_level_new %old, which is for the ease of our dialect lowering.

We have an optimization pass called alloc-to-inplace that replaces the allocation version to inplace version (that Lattigo prefers), but still two versions of them are needed in case such replacement does not succeed.

As for why DropLevel is needed by the compiler. The philosophy is that the compiler should manage all the metadata on its own so corresponding instructions should be issued. Specifically, this instruction is used by the scale management pass (#1459 in-progress) where reducing to certain level is needed by cross-level operations.

[Pro7ech]

I see. But drop level isn't even used for scale management in Lattigo. It was initially added to match the API of https://github.com/kimandrik/HEAAN. Contrary to Open FHE, Lattigo doesn't use a different scale for each level. Instead the scale is maintained to the default scale by tweaking the scaling factor of the inputs to ensure the scaling factor, before a rescaling, is the product between the default scale and the prime to be consumed. Most of it is done automatically (e.g. when performing pt-ct ops), but some of it falls on the user responsibility (ensuring that ct-ct ops have the same scalr). Cross level operations are thus just taking the minimum level of the inputs, without having to do intermediate rescaling to match scales.

Open FHE's approach can be emulated, but additional care must be given, such as manually specifying the encoding factors, else cross level operations will result in precision loss.

Just making sure it is not mistaken for something it is not, the point being that, in Lattigo, wether this method is called or not before cross level operations will not have any effect on the output ciphertext.

[ZenithalHourlyRate]

Open FHE's approach can be emulated, but additional care must be given, such as manually specifying the encoding factors, else cross level operations will result in precision loss.

The intended solution of the in-progress PR for emulating Openfhe's cross-level behavior in Lattigo is indeed manually specifying the encoding factors by multiplying by 1 with scaling factor (unfortunately HEIR does not suport multiply with constant now #1604)

pt = bgv.NewPlaintext
pt.Scale = [compiler specified]
encoder.Encode([1, 1, ...], pt)

The emulation behavior is one baseline approach for enabling the basic scaling factor management functionality of HEIR (as HEIR does not have fine control over other backends). I do not think we will pin to that solution and further techniques (like the one Lattigo does) could be ported to HEIR.

Just making sure it is not mistaken for something it is not, the point being that, in Lattigo, wether this method is called or not before cross level operations will not have any effect on the output ciphertext.

In my understanding Lattigo on its own management does not need such API. HEIR should be able to manage the ciphertext such that matchScaleThenEvaluateInPlace will not be called, which
means Lattigo's management is bypassed.

Will PR Lattigo to try to add this API.

As for the API itself, after the discussion I think I can close that request as Lattigo itself does not need it, and HEIR can emulate it anyway.

[Pro7ech]

Thanks for the clarification :)