BGV/CKKS: support scale management #1459

ZenithalHourlyRate · 2025-02-24T14:27:18Z

I am afraid we can only do this for Lattigo backend, as Openfhe does not have explicit port for setting scale. Although the policy implemented is in line with Openfhe's implementation, and Openfhe does that automatically.

The detailed rational/impl of the scale management should be put in design doc within this PR.

There are a few changes to support scale

mgmt.level_reduce, mgmt.adjust_scale op to support corresponding operation
Modify secret-insert-mgmt-bgv to use these ops to handle cross level op, where adjust_scale is a place holder
--validate-noise will generate parameters aware of these management op
--populate-scale (better name wanted) to concretely fill the scale based on the parameter

TODO

Deal with the complicacy caused by the include-first-mul option.
LWE dialect scale support
Lowering to Lattigo backend.
Option to just ignore these mgmt op for Openfhe, as it has automation. See also Support different flavor of lowering in --mlir-to-<scheme> #1420
Handle ct-pt op, need to set pt scale as ct scale

Cc @AlexanderViand-Intel: A comment on #1295 (comment) is that, the two backends we have can safely Add(ct0, ct1) with ciphertexts of different scale as internally when they find scale mismatching they would just adjust scale themselves. So the mixed-degree option for optimize-relinearization can be on without affecting correctness, though the noise is different. The merging of this PR does not fix the scale mismatching problem possibly induced by optimize-relinearization for our current two backends, but it indeed pave the way for our own poly backend which must be scale aware.

Example

the input mlir

func.func @cross_level_add(%base: tensor<4xi16> {secret.secret}, %add: tensor<4xi16> {secret.secret}) -> tensor<4xi16> {
  // same level
  %base0 = arith.addi %base, %add : tensor<4xi16>
  // increase one level
  %mul1 = arith.muli %base0, %base0 : tensor<4xi16>
  // cross level add
  %base1 = arith.addi %mul1, %add : tensor<4xi16>
  // increase one level
  %mul2 = arith.muli %base1, %base1 : tensor<4xi16>
  // cross level add
  %base2 = arith.addi %mul2, %add : tensor<4xi16>
  // increase one level
  %mul3 = arith.muli %base2, %base2 : tensor<4xi16>
  // cross level add
  %base3 = arith.addi %mul3, %add : tensor<4xi16>
  return %base3 : tensor<4xi16>
}

After secret-insert-mgmt-bgv, we get

      %1 = arith.addi %input0, %input1 {mgmt.mgmt = #mgmt.mgmt<level = 3>} : tensor<4xi16>
      %2 = arith.muli %1, %1 {mgmt.mgmt = #mgmt.mgmt<level = 3, dimension = 3>} : tensor<4xi16>
      %3 = mgmt.relinearize %2 {mgmt.mgmt = #mgmt.mgmt<level = 3>} : tensor<4xi16>
      %4 = arith.addi %3, %input1 {mgmt.mgmt = #mgmt.mgmt<level = 3>} : tensor<4xi16>
      %5 = mgmt.modreduce %4 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
      %6 = arith.muli %5, %5 {mgmt.mgmt = #mgmt.mgmt<level = 2, dimension = 3>} : tensor<4xi16>
      %7 = mgmt.relinearize %6 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
      %8 = mgmt.adjust_scale %input1 {mgmt.mgmt = #mgmt.mgmt<level = 3>} : tensor<4xi16>
      %9 = mgmt.modreduce %8 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
      %10 = arith.addi %7, %9 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
      %11 = mgmt.modreduce %10 {mgmt.mgmt = #mgmt.mgmt<level = 1>} : tensor<4xi16>
      %12 = arith.muli %11, %11 {mgmt.mgmt = #mgmt.mgmt<level = 1, dimension = 3>} : tensor<4xi16>
      %13 = mgmt.relinearize %12 {mgmt.mgmt = #mgmt.mgmt<level = 1>} : tensor<4xi16>
      %14 = mgmt.level_reduce %input1 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
      %15 = mgmt.adjust_scale %14 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
      %16 = mgmt.modreduce %15 {mgmt.mgmt = #mgmt.mgmt<level = 1>} : tensor<4xi16>
      %17 = arith.addi %13, %16 {mgmt.mgmt = #mgmt.mgmt<level = 1>} : tensor<4xi16>
      %18 = mgmt.modreduce %17 {mgmt.mgmt = #mgmt.mgmt<level = 0>} : tensor<4xi16>

where adjust_scale has no concrete scale parameter

After --validate-noise and --populate-scale, we will get the per-level scale, and the value to fill for each adjust_scale

PopulateScale: scale = [57802, 46604, 21845, 1, ]
PopulateScale: scaleBig = [60481, 36636, 29128, 1, ]
PopulateScale: adjustScale = [1, 2528, 13431, 21845, ]
Propagate ScaleState(1) to <block argument> of type 'tensor<4xi16>' at index: 0
Propagate ScaleState(1) to <block argument> of type 'tensor<4xi16>' at index: 1
Propagate ScaleState(1) to %1 = arith.addi %input0, %input1 {mgmt.mgmt = #mgmt.mgmt<level = 3>} : tensor<4xi16>
Propagate ScaleState(1) to %2 = arith.muli %1, %1 {mgmt.mgmt = #mgmt.mgmt<level = 3, dimension = 3>} : tensor<4xi16>
Propagate ScaleState(1) to %3 = mgmt.relinearize %2 {mgmt.mgmt = #mgmt.mgmt<level = 3>} : tensor<4xi16>
Propagate ScaleState(1) to %4 = arith.addi %3, %input1 {mgmt.mgmt = #mgmt.mgmt<level = 3>} : tensor<4xi16>
Propagate ScaleState(21845) to %5 = mgmt.modreduce %4 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
Propagate ScaleState(29128) to %6 = arith.muli %5, %5 {mgmt.mgmt = #mgmt.mgmt<level = 2, dimension = 3>} : tensor<4xi16>
Propagate ScaleState(29128) to %7 = mgmt.relinearize %6 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
Propagate ScaleState(21845) to %8 = mgmt.adjust_scale %input1 {mgmt.mgmt = #mgmt.mgmt<level = 3>, scale = 21845 : i64} : tensor<4xi16>
Propagate ScaleState(29128) to %9 = mgmt.modreduce %8 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
Propagate ScaleState(29128) to %10 = arith.addi %7, %9 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
Propagate ScaleState(46604) to %11 = mgmt.modreduce %10 {mgmt.mgmt = #mgmt.mgmt<level = 1>} : tensor<4xi16>
Propagate ScaleState(36636) to %12 = arith.muli %11, %11 {mgmt.mgmt = #mgmt.mgmt<level = 1, dimension = 3>} : tensor<4xi16>
Propagate ScaleState(36636) to %13 = mgmt.relinearize %12 {mgmt.mgmt = #mgmt.mgmt<level = 1>} : tensor<4xi16>
Propagate ScaleState(1) to %14 = mgmt.level_reduce %input1 {mgmt.mgmt = #mgmt.mgmt<level = 2>} : tensor<4xi16>
Propagate ScaleState(13431) to %15 = mgmt.adjust_scale %14 {mgmt.mgmt = #mgmt.mgmt<level = 2>, scale = 13431 : i64} : tensor<4xi16>
Propagate ScaleState(36636) to %16 = mgmt.modreduce %15 {mgmt.mgmt = #mgmt.mgmt<level = 1>} : tensor<4xi16>
Propagate ScaleState(36636) to %17 = arith.addi %13, %16 {mgmt.mgmt = #mgmt.mgmt<level = 1>} : tensor<4xi16>
Propagate ScaleState(57802) to %18 = mgmt.modreduce %17 {mgmt.mgmt = #mgmt.mgmt<level = 0>} : tensor<4xi16>

Where the first three lines are purely calculated from bgv scheme parameter and the later is the analysis to validate whether the scale matches.

The initial scaling factor is chosen to be 1 for both include-first-mul={true,false}, as for include-first-mul=false, the scaling factor of the last level must be the same, so we have 1 * 1 = 1.

ZenithalHourlyRate · 2025-03-03T16:26:04Z

It has been quite messy supporting scale, as we have to change these things below

mgmt insertion policy for both BGV and CKKS
- insert rescale after mult, before mult, and before mult with first mult
- note that the original cross-level policy for CKKS is wrong
populate scale with regard to all three rescale insertion policy
LWE type, which if we add a new field quite a bunch of test file need to change
Two backends

My idea is to skip the LWE type support and use attribute to pass information temporarily, and skip openfhe as it does support that anyway.

The pipeline works now for Lattigo, see example

func.func @cross_level_add(%base: tensor<4xi16> {secret.secret}, %add: tensor<4xi16> {secret.secret}) -> tensor<4xi16> {
  // increase one level
  %mul1 = arith.muli %base, %add : tensor<4xi16>
  // cross level add
  %base1 = arith.addi %mul1, %add : tensor<4xi16>
  return %base1 : tensor<4xi16>
}

After properly managed and calculation of scale we get

      %1 = mgmt.modreduce %input0 {mgmt.mgmt = #mgmt.mgmt<level = 1, scale = 4>} : tensor<4xi16>
      %2 = mgmt.modreduce %input1 {mgmt.mgmt = #mgmt.mgmt<level = 1, scale = 4>} : tensor<4xi16>
      %3 = arith.muli %1, %2 {mgmt.mgmt = #mgmt.mgmt<level = 1, dimension = 3, scale = 16>} : tensor<4xi16>
      %4 = mgmt.relinearize %3 {mgmt.mgmt = #mgmt.mgmt<level = 1, scale = 16>} : tensor<4xi16>
      // need to adjust the scale by mul_const delta_scale
      %5 = mgmt.adjust_scale %input1 {delta_scale = 4 : i64, mgmt.mgmt = #mgmt.mgmt<level = 2, scale = 4>, scale = 4 : i64} : tensor<4xi16>
      %6 = mgmt.modreduce %5 {mgmt.mgmt = #mgmt.mgmt<level = 1, scale = 16>} : tensor<4xi16>
      %7 = arith.addi %4, %6 {mgmt.mgmt = #mgmt.mgmt<level = 1, scale = 16>} : tensor<4xi16>
      %8 = mgmt.modreduce %7 {mgmt.mgmt = #mgmt.mgmt<level = 0, scale = 65505>} : tensor<4xi16>

adjust_scale is materialized as the following

    %cst = arith.constant dense<1> : tensor<4xi16>
    %pt = lwe.rlwe_encode %cst {encoding = #full_crt_packing_encoding, lwe.scale = 4 : i64, ring = #ring_Z65537_i64_1_x4_} : tensor<4xi16> -> !pt
    %ct_5 = bgv.mul_plain %ct_0, %pt : (!ct_L2_, !pt) -> !ct_L2_

When emitted to lattigo with debug handler, we can observe the scale change exactly the same

Input
  Scale:  1
Input
  Scale:  1
lattigo.bgv.rescale_new
  Scale:  4
lattigo.bgv.rescale_new
  Scale:  4
lattigo.bgv.mul_new
  Scale:  16
lattigo.bgv.relinearize_new
  Scale:  16
// this is adjust_scale
lattigo.bgv.mul_new
  Scale:  4
lattigo.bgv.rescale_new
  Scale:  16
lattigo.bgv.add_new
  Scale:  16
lattigo.bgv.rescale_new
  Scale:  65505
Result [4 9 16 25]

j2kun · 2025-03-03T17:57:07Z

Talking about this in office hours. Some ideas:

Have one integer scaling factor attribute that specifies its own bitwidth, to support large bitwidth scaling factors (e.g., for CKKS). The the lowerings to a particular backend (e.g., C++/OpenFHE) would need to pick the appropriate type (perhaps long double) to represent that scaling factor in the target language.
Make the scaling factor attribute optional on the LWE type to avoid having to update the entire codebase, and raise errors or handle the default cause when the scaling factor is not present. We could also have some backlog work to go update the rest of the codebase so that there are scaling factors and we can later remove optionality.

ZenithalHourlyRate · 2025-03-05T17:50:58Z

Until now 99 files changed...would be insane if more changes are introduced. Ask for review now because many technical changes need discussion/decision. Doc/cleanup are not done yet.

Loop problem

The hard part of supporting scale management is that, making scale match everywhere. The current state of the PR will break the loop support.

The intrinsic problem with loop support is that, we need to make it FHE-aware enough. This is the same problem as LevelAnalysis in #1181, where we want to know some invariant kept by the loop. We used to think about keeping level/dimension the same, now we need to consider more to make the scale the same.

The following example shows the current matmul code can not live through the scale analysis

affine.for %result_tensor (assume 2^45 scale initially)
  %a, %const scale 2^45, 
  %0 = mul_plain %a, %const // result scale 2^90
  %1 = add %0, result // scale 2^90
  tensor.insert %1 into %result_tensor // scale mismatch!

This centainly need some insight into the loop.

We can not even deal with unrolled version because we need some kind of back-propagation:

%result = tensor.empty // how do we know it when we encounter it
tensor.insert %sth into %result // until now do we know

Current status

Changed secret-insert-mgmt with three different way of inserting mgmt ops, note that these different ways has different indication of initial scaling factor requirement
- for before-mul-include-first-mul, we need to encode at double degree like 2^90.
In secret-insert-mgmt, cross-level op now will be adjusted with level_reduce + adjust_level + mod_reduce to the same level.
- adjust_level at this time will be adjust_level { scale = -1 } as we do now know the scale now
Now annotate-mgmt also annotates the MgmtAttr for plaintext because we need to know the scale of the plaintext. As multiple arith.constant will be canonicalied away, mgmt.no_op is introduced as a placeholder for mgmt attr
generate-param will generate param as usual
populate-scale now knows the param and it can determine the scale of each ciphertext, then it will fill the adjust_scale with concrete scale by back-propagation style heuristic, then adjust_scale is lowered to mul_plain %ct, 1 where arith.constant 1 has the mgmt attr of scale = N. Note that this is a metadata change instead of message change.
secret-to-<scheme> takes the scale into LWE type
refactored LWE type related dialect on code structure, with verifier on scale
Make backend aware of scale (lattigo can set pt.Scale = NewScale(Pow(2, 90)), for openfhe we can not

Problem with backend

Openfhe does the automation itself, so the mul_plain %ct, 1 there does not have any metadata effect. In constrast it will introduce noise, and openfhe itself then does the adjustment itself, introducing more nosie. We might want to just turn off adjust_scale for openfhe backend, but then the scale matching problem emerges in LWE type system, where we might need to lwe.opaque_scale_cast indicating the backend is doing its own job.
For Lattigo BGV, our adjust to the scale is exact and Lattigo likes it. For CKKS it is not the case as there will be tiny scale mismatch (2^44.9999999 != 2^45) and it will automatically rescale somewhere, make more level assumption and will fail execution when it find no more level to consume.

github-advanced-security · 2025-03-10T11:22:01Z

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

ZenithalHourlyRate · 2025-03-10T16:01:25Z

Until now 99 files changed...would be insane if more changes are introduced.

The hard part of supporting scale management is that, making scale match everywhere. The current state of the PR will break the loop support.

I think I am going to pend this PR as the loop part is important. I intend to open another PR that possibly add a pass taking a loop and analyse if it is expressible by FHE world, for at least LevelAnalysis, then we can make ScaleAnalysis happy.

In the meantime, some non-critical part of this is split out into like #1540 and further PRs.

j2kun · 2025-03-11T04:14:28Z

I am still digesting many of these details, but this one stuck out for me:

We can not even deal with unrolled version because we need some kind of back-propagation

We had the same problem with layout management, a tensor.empty has no intrinsic layout when we visit it. We added the assign_layout op to give it a default placeholder layout, and then a back-propagation pass would support merging downstream layout changes into this op to "override" it with a better layout discovered later. Could you use the same idea for scale? I.e., set some default assign_scale in a forward-propagation pass, then in a backward propagation pass you could hoist adjust_scale ops backward through the IR, and if you encounter assign_scale you can replace it with the desired adjusted scale and then use that to set the scale of the initial empty tensor. In the forward pass you could insert adjust_scale ops whenever, e.g., something with the wrong scale tries to insert into a tensor with a different scale.

@asraa if this makes sense for scale, this is also making me think: how generalizable is our Fhelipe forward-backward propagation pass to concepts beyond layouts? Could we have an agnostic sort of "compatibility optimizer" pass that allows one to plug in the ops for "assign" and "convert" and fit to a cost model interface? Or am I just wallowing in abstraction for its own sake 🤷‍♂️

Copilot

Pull Request Overview

This PR adds design documentation for managing ciphertext scale in BGV and CKKS schemes, explaining the required operations and strategies. Key changes include:

A detailed description of ciphertext management operations.
An explanation of modulus switching, relinearization, and scale management in BGV.
An overview of how the design applies similarly to CKKS.

Files not reviewed (19)

lib/Analysis/AddAndKeySwitchCountAnalysis/AddAndKeySwitchCountAnalysis.cpp: Language not supported
lib/Analysis/DimensionAnalysis/DimensionAnalysis.cpp: Language not supported
lib/Analysis/DimensionAnalysis/DimensionAnalysis.h: Language not supported
lib/Analysis/LevelAnalysis/LevelAnalysis.cpp: Language not supported
lib/Analysis/LevelAnalysis/LevelAnalysis.h: Language not supported
lib/Analysis/MulDepthAnalysis/BUILD: Language not supported
lib/Analysis/MulDepthAnalysis/MulDepthAnalysis.cpp: Language not supported
lib/Analysis/NoiseAnalysis/BFV/NoiseAnalysis.cpp: Language not supported
lib/Analysis/NoiseAnalysis/BGV/NoiseAnalysis.cpp: Language not supported
lib/Analysis/ScaleAnalysis/BUILD: Language not supported
lib/Analysis/ScaleAnalysis/ScaleAnalysis.h: Language not supported
lib/Dialect/Mgmt/IR/BUILD: Language not supported
lib/Dialect/Mgmt/IR/MgmtAttributes.cpp: Language not supported
lib/Dialect/Mgmt/IR/MgmtAttributes.h: Language not supported
lib/Dialect/Mgmt/IR/MgmtAttributes.td: Language not supported
lib/Dialect/Mgmt/IR/MgmtCanonicalization.td: Language not supported
lib/Dialect/Mgmt/IR/MgmtOps.cpp: Language not supported
lib/Dialect/Mgmt/IR/MgmtOps.td: Language not supported
lib/Dialect/Mgmt/Transforms/AnnotateMgmt.cpp: Language not supported

docs/content/en/docs/Design/management.md

ZenithalHourlyRate · 2025-03-31T07:09:07Z

After dependent PRs merged #1540 #1586 #1611 this PR now is much cleaner, still it is big enough (85 files changed with 3k additional lines)

Notable changes

Now Loop support is back-alive, as we can skip management passes entirely by specifying backend=openfhe, and additionally providing a scheme parameter could skip all the analysis so infinite loop like AnnotateMgmt for programs with loops fails - LevelAnalysis yields infinite loop #1364 won't happen.
Only the lattigo pipeline has scale management. And all the messy code (back-propagation mentioned above) is now handled by Backward Analysis provided by MLIR framework, i.e. ScaleAnalysisBackward. A similar LevelAnalysisBackward is also introduced. The backward analyses are responsible for handling plaintext and adjust_scale, which naturally needs back-prop from ciphertext.
For plaintext operand, mgmt.no_op is inserted for them as a holder for mgmt attribute, in case canonicalizer merges arith.constant despite they have different annotation.
adjust_scale is materialized to mul_plain %ct, %c1 with %c1 encoded at specific scaling factor in populate-scale-<scheme>
different modulus switching policy and scale management policy test cases and e2e test cases are added.

Other parts are described in the management.md design doc.

j2kun

I still have to review lib/Transforms, but the Scale analysis looks good so far and I think the direction is good. I am very excited about the documentation writeup here. I apologize for all the suggested edits, but I hope the result will be well polished as a result.

lib/Dialect/Mgmt/IR/MgmtOps.td

lib/Dialect/Mgmt/IR/MgmtCanonicalization.td

lib/Analysis/LevelAnalysis/LevelAnalysis.h

lib/Dialect/Mgmt/IR/MgmtOps.td

lib/Analysis/ScaleAnalysis/ScaleAnalysis.h

lib/Analysis/ScaleAnalysis/ScaleAnalysis.cpp

lib/Parameters/CKKS/Params.h

lib/Transforms/PopulateScale/PopulateScaleBGV.cpp

lib/Transforms/SecretInsertMgmt/SecretInsertMgmtPatterns.cpp

lib/Transforms/SecretInsertMgmt/SecretInsertMgmtPatterns.h

lib/Utils/ContextAwareConversionUtils.h

tests/Examples/lattigo/bgv/cross_level/cross_level.mlir

tests/Examples/lattigo/ckks/cross_level/cross_level.mlir

ZenithalHourlyRate

Sorry for not replying every review comments and directly marking them as resolved as people will receive too many emails for them. These are handled in code accordingly.

(one annoying part of github review is that once I push a new version and comments become outdated, I could not submit reply comments in batch)

As for those questions, I put explanation in the code comment as I believe every other person will have similar questions.

docs/content/en/docs/Design/management.md

lib/Analysis/LevelAnalysis/LevelAnalysis.cpp

lib/Dialect/Mgmt/IR/MgmtCanonicalization.td

lib/Parameters/CKKS/Params.h

lib/Transforms/PopulateScale/PopulateScaleBGV.cpp

lib/Transforms/PopulateScale/PopulateScaleCKKS.cpp

lib/Transforms/SecretInsertMgmt/SecretInsertMgmtPatterns.cpp

ZenithalHourlyRate · 2025-04-02T15:29:52Z

Fixes #1169 #1364 #785

j2kun

One minor conflict to resolve and then we are good to go!

ZenithalHourlyRate

Rebased to resolve merge conflict

ZenithalHourlyRate · 2025-04-03T06:48:33Z

lib/Dialect/CKKS/IR/CKKSOps.td

-def CKKS_MulPlainOp : CKKS_CiphertextPlaintextOp<"mul_plain", [InferTypeOpAdaptor, AllCiphertextTypesMatch, Commutative]> {
+// MulPlain op result ciphertext type could be different from the input
+def CKKS_MulPlainOp : CKKS_CiphertextPlaintextOp<"mul_plain", [InferTypeOpAdaptor, Commutative]> {


Cc @asraa on #1620: BGV/CKKS MulPlainOp does not require result and input ciphertext types to be the same in that they may have different scale. The verification of result scale = ct scale + pt scale is done by InferTypeOpAdaptor in

heir/lib/Dialect/LWE/IR/LWEOps.h

Lines 69 to 78 in 55d883d

// verify plaintext space matches

auto ctPlaintext = ct.getPlaintextSpace();

auto ptPlaintext = pt.getPlaintextSpace();

auto outPlaintext = out.getPlaintextSpace();

if (outPlaintext != inferMulOpPlaintextSpaceAttr(op->getContext(),

ctPlaintext, ptPlaintext)) {

return op->emitOpError() << "output plaintext space does not match";

}

return success();

}

ZenithalHourlyRate · 2025-04-04T06:54:49Z

Rebased to resolve merge conflict

-- 39aef37 by Zenithal <i@zenithal.me>: BGV/CKKS: support scale management COPYBARA_INTEGRATE_REVIEW=#1459 from ZenithalHourlyRate:bgv-scaled 39aef37 PiperOrigin-RevId: 743968761

ZenithalHourlyRate force-pushed the bgv-scaled branch from ac97379 to 8253471 Compare March 2, 2025 14:15

ZenithalHourlyRate force-pushed the bgv-scaled branch 2 times, most recently from 50174dd to 180b6c9 Compare March 5, 2025 08:06

ZenithalHourlyRate marked this pull request as ready for review March 5, 2025 17:21

ZenithalHourlyRate changed the title ~~BGV: support scale management~~ BGV/CKKS: support scale management Mar 5, 2025

ZenithalHourlyRate force-pushed the bgv-scaled branch from 4cb5285 to c404362 Compare March 10, 2025 11:21

ZenithalHourlyRate marked this pull request as draft March 10, 2025 11:22

ZenithalHourlyRate mentioned this pull request Mar 10, 2025

LWE: refactor, scale-related verifier and support level reduce #1540

Merged

ZenithalHourlyRate force-pushed the bgv-scaled branch 2 times, most recently from d24ca65 to bdb2625 Compare March 11, 2025 06:49

ZenithalHourlyRate mentioned this pull request Mar 19, 2025

Support different flavor of lowering in --mlir-to-<scheme> #1420

Open

ZenithalHourlyRate force-pushed the bgv-scaled branch from bdb2625 to aa4e0c1 Compare March 23, 2025 12:45

ZenithalHourlyRate mentioned this pull request Mar 30, 2025

Lattigo: use DropLevel API for level reduce #1626

Merged

ZenithalHourlyRate force-pushed the bgv-scaled branch 4 times, most recently from 471e107 to 6e057b5 Compare March 31, 2025 06:47

ZenithalHourlyRate marked this pull request as ready for review March 31, 2025 06:48

ZenithalHourlyRate requested a review from Copilot March 31, 2025 06:48

Copilot AI reviewed Mar 31, 2025

View reviewed changes

ZenithalHourlyRate force-pushed the bgv-scaled branch 2 times, most recently from b8523c0 to 31b8770 Compare April 1, 2025 00:04

j2kun requested changes Apr 1, 2025

View reviewed changes

ZenithalHourlyRate mentioned this pull request Apr 2, 2025

Implement parameter generation of "Approximate Homomorphic Encryption with Reduced Approximation Error" #1640

Open

2 tasks

ZenithalHourlyRate commented Apr 2, 2025

View reviewed changes

ZenithalHourlyRate force-pushed the bgv-scaled branch from 31b8770 to b1edcc2 Compare April 2, 2025 14:54

ZenithalHourlyRate mentioned this pull request Apr 2, 2025

Make LevelAnalysis/DimensionAnalysis aware of affine.for loop #1181

Open

j2kun approved these changes Apr 3, 2025

View reviewed changes

ZenithalHourlyRate force-pushed the bgv-scaled branch from b1edcc2 to 39aef37 Compare April 3, 2025 06:44

ZenithalHourlyRate commented Apr 3, 2025

View reviewed changes

j2kun added the pull_ready Indicates whether a PR is ready to pull. The copybara worker will import for internal testing label Apr 3, 2025

ZenithalHourlyRate force-pushed the bgv-scaled branch from 39aef37 to 659d4b6 Compare April 4, 2025 06:54

BGV/CKKS: support scale management

a049849

ZenithalHourlyRate force-pushed the bgv-scaled branch from 659d4b6 to a049849 Compare April 4, 2025 07:01

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

BGV/CKKS: support scale management #1459

BGV/CKKS: support scale management #1459

ZenithalHourlyRate commented Feb 24, 2025 •

edited

Loading

ZenithalHourlyRate commented Mar 3, 2025

j2kun commented Mar 3, 2025

ZenithalHourlyRate commented Mar 5, 2025

github-advanced-security bot commented Mar 10, 2025

ZenithalHourlyRate commented Mar 10, 2025

j2kun commented Mar 11, 2025 •

edited

Loading

Copilot AI left a comment

ZenithalHourlyRate commented Mar 31, 2025

j2kun left a comment

ZenithalHourlyRate left a comment

ZenithalHourlyRate commented Apr 2, 2025

j2kun left a comment

ZenithalHourlyRate left a comment

ZenithalHourlyRate Apr 3, 2025

ZenithalHourlyRate commented Apr 4, 2025

	// verify plaintext space matches
	auto ctPlaintext = ct.getPlaintextSpace();
	auto ptPlaintext = pt.getPlaintextSpace();
	auto outPlaintext = out.getPlaintextSpace();
	if (outPlaintext != inferMulOpPlaintextSpaceAttr(op->getContext(),
	ctPlaintext, ptPlaintext)) {
	return op->emitOpError() << "output plaintext space does not match";
	}
	return success();
	}

BGV/CKKS: support scale management #1459

Are you sure you want to change the base?

BGV/CKKS: support scale management #1459

Conversation

ZenithalHourlyRate commented Feb 24, 2025 • edited Loading

TODO

Example

ZenithalHourlyRate commented Mar 3, 2025

j2kun commented Mar 3, 2025

ZenithalHourlyRate commented Mar 5, 2025

Loop problem

Current status

Problem with backend

github-advanced-security bot commented Mar 10, 2025

ZenithalHourlyRate commented Mar 10, 2025

j2kun commented Mar 11, 2025 • edited Loading

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

ZenithalHourlyRate commented Mar 31, 2025

j2kun left a comment

Choose a reason for hiding this comment

ZenithalHourlyRate left a comment

Choose a reason for hiding this comment

ZenithalHourlyRate commented Apr 2, 2025

j2kun left a comment

Choose a reason for hiding this comment

ZenithalHourlyRate left a comment

Choose a reason for hiding this comment

ZenithalHourlyRate Apr 3, 2025

Choose a reason for hiding this comment

ZenithalHourlyRate commented Apr 4, 2025

ZenithalHourlyRate commented Feb 24, 2025 •

edited

Loading

j2kun commented Mar 11, 2025 •

edited

Loading