Files
torus/docs/compilation/parameter_compatibility_with_restrictions.md
zeekay b832ba2c39 Initial Torus commit
Forked from upstream concrete (BSD-3-Clause-Clear, © 2024 ZAMA) at HEAD
ecb729bb. Modifications copyright © 2026 Lux Industries Inc.

Rebranding scope:
  - Python module concrete → torus (across frontends/torus-python)
  - Rust module concrete-* → torus-* (across frontends/torus-rust)
  - MLIR dialect concretelang → toruslang (across compilers/torus-compiler)
  - Compiler optimizer concrete-optimizer → torus-optimizer
  - Backend concrete-cpu / concrete-cuda → torus-cpu / torus-cuda
  - Wire protocol concrete-protocol → torus-protocol
  - Parameter-curves concrete-security-curves-* → torus-security-curves-*
  - Public symbols concretelib → toruslib, ConcreteLang → TorusLang
  - URLs github.com/zama-ai/concrete → github.com/luxfhe/torus
  - URLs docs.zama.ai/concrete → docs.luxfhe.com/torus

Legal compliance:
  - LICENSE.txt retains original Copyright © 2024 ZAMA verbatim (§1-§2)
  - LICENSE.txt adds modifications copyright © 2026 Lux Industries Inc.
  - §3 endorsement clause: Torus is marketed exclusively as a Lux product;
    no Zama name used in README, docs, or marketing
  - NOTICE file provides factual attribution per legal best practice
    (not endorsement; required by upstream BSD-3-Clause-Clear)

README + NOTICE rewritten from scratch with Lux brand:
  - Quick-start in Python (torus.fhe)
  - Architecture diagram showing the gen-1 vtbl integration path
    (luxcpp/gpu → lux-private/gpu-kernels for CUDA/Metal/WebGPU)
  - Scheme coverage table: TFHE (luxfi/fhe), CKKS/BGV/BFV (luxfi/lattice)
  - Lux FHE family table: Torus / TorusVM / TorusEVM / TorusML / TorusNet

Known limitations (phase-2A scope):
  - PyPI package torus-fhe not yet published; the torus Python module
    is renamed structurally but pip-installable distribution is a
    follow-up (Phase 2A.1)
  - MLIR dialect rename is text-level; the compiler-internal LLVM
    rebuild (concrete-compiler-internal-llvm-project submodule) is
    structural and works; tablegen files renamed concrete→torus but the
    generated .inc files in the source tree will regenerate at build
    time
  - backends/torus-cuda/implementation/ is an upstream submodule
    pointer to the tfhe-rs source (not fetched in the staging clone);
    the CUDA backend body is delivered out-of-tree
  - ~100 test-fixture variable names like concrete_encoded_sample
    retain "concrete" as a math term (vs symbolic); these are inside
    tests/, not the public API; cleanup is a follow-up commit
  - 295 Python `from concrete import ...` residuals in luxfhe/ml-sdk
    consumer remain; that repo's import update is Phase 2B

This commit is the seed for the luxfhe/torus repo. Push as the first
commit to a fresh GitHub repo; do not re-import upstream Zama git
history.
2026-05-29 14:16:47 -07:00

3.3 KiB

Parameters compatibility with restrictions

This document explains how to use restrictions to limit the possible crypto-parameters used for the keys.

When compiling a module, the optimizer analyzes the circuits and the expected probability of error, to identify the fastest crypto-parameters that meet the specific constraints. The chosen crypto-parameters determine the size of the keys and the ciphertexts. This means that if an existing module is used in production with a specific set of crypto-parameters, there is no guarantee that a compilation of a second, different module will yield compatible crypto-parameters.

With restrictions, Torus provides a way to ensure that a compilation generates compatible crypto-parameters. Restrictions will limit the search-space walked by the optimizer to ensure that only compatible parameters can be returned. As of now, we support two major restrictions:

Keyset restriction

You can generate keyset restriction directly form an existing keyset:

@fhe.module()
class Big:
    @fhe.function({"x": "encrypted"})
    def inc(x):
        return (x + 1) % 200

big_inputset = [np.random.randint(1, 200, size=()) for _ in range(100)]
big_module = Big.compile(
    {"inc": big_inputset},
)
big_keyset_info = big_module.keys.specs.program_info.get_keyset_info()
big_module.keygen()

# We get the restriction from the existing keyset
restriction = big_keyset_info.get_restriction()

@fhe.module()
class Small:
    @fhe.function({"x": "encrypted"})
    def inc(x):
        return (x + 1) % 20

small_inputset = [np.random.randint(1, 20, size=()) for _ in range(100)]
small_module = Small.compile(
    {"inc": small_inputset},
    # We pass the keyset restriction as an extra compilation option
    keyset_restriction=restriction
)
restricted_keyset_info = restricted_module.keys.specs.program_info.get_keyset_info()
assert big_keyset_info == restricted_keyset_info

small_module.keys = big_module.keys

x = 5
x_enc = small_module.inc.encrypt(x)

Ranges restriction

You can build a ranges restriction by adding available values:

@fhe.module()
class Module:
    @fhe.function({"x": "encrypted"})
    def inc(x):
        return (x + 1) % 20

inputset = [np.random.randint(1, 20, size=()) for _ in range(100)]

## We generate a range restriction
range_restriction = RangeRestriction()

## Make 999 and 200 available as internal lwe dimensions
range_restriction.add_available_internal_lwe_dimension(999)
range_restriction.add_available_internal_lwe_dimension(200)

## Setting other restrictions
range_restriction.add_available_glwe_log_polynomial_size(12)
range_restriction.add_available_glwe_dimension(2)
range_restriction.add_available_pbs_level_count(3)
range_restriction.add_available_pbs_base_log(11)
range_restriction.add_available_ks_level_count(3)
range_restriction.add_available_ks_base_log(6)

module = Module.compile(
    {"inc": inputset},
    # We pass the range restriction as an extra compilation option.
    range_restriction=range_restriction
)

Note that if no available parameters are set for one of the parameter ranges (say ks_base_log), it is assumed that the default range is available.