zeekay
b832ba2c39
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.
3.6 KiB
v0 Parameters
The v0-parameters tool provides crypto-parameters that guarantee security, correctness and fast
computation without prior knowledge of the crypto-parameter optimization.
For a given (precision, log2(norm2)), these parameters can be used in a TFHE integer circuit where the maximal integer precision is precision and the maximal norm2 between table lookups is 2^log2(norm2).
The norm2 is the sum of the square of weights in multisum between table lookups or graph inputs (weights on the same input must first be combined as a single weight).
The probability of error is the maximal acceptable probability of error of each table lookup.
It can also be used to explore the crypto-parameter space w.r.t. the 2-norm of the dot product, the precision or even the failure probability.
For now, we only support two kind of atomic patterns but more will be added in the near future.
Supported Atomic Patterns
Default Atomic Pattern
The default atomic pattern is composed of a dot product between ciphertexts and integer weights, an LWE-to-LWE keyswitch and a PBS i.e.
This atomic pattern allows to compute over encrypted data a dot product and a lookup-table evaluation for precision between 1 and 8 (with the default failure probability) and 2-norm between 2^0 and 2^25. The 2-norm is defined as the 2-norm v of the weights of the Dot Product. It is used as a metric to quantify the impact of the leveled operations between two PBS on the noise (here a DotProduct). Note that an atomic pattern can be described by its precision and 2-norm but only in the case that every inputs are independents from one another (regarding the noise).
New Atomic Pattern
Another atomic pattern is available leveraging the new WoP-PBS (Without-Padding Programmable Bootstrapping) described in this paper. It is composed of a dot product between ciphertexts and integer weights and a WoP-PBS.
Using this new AP, we can find parameters for precision up to 16 bits 🥳 using the optional flag --wop-pbs like that
cargo run --release -- --wop-pbs
Usage
The v0-parameters tool can take several parameters as arguments. The summary of all available
arguments is accessible by running in the v0-parameters/ folder
cargo run --release -- --help
As an alternative you can use the optimizer script in the root directory:
./optimizer --help
By default, the optimization is done on the default AP (DotProduct -> Ks -> PBS) for every available
precision and for every 2-norm. If not specified, the correctness of the computation is guaranteed
up to a failure probability of 2^-13.9. This can be changed using the --p-error
optional argument.
Advanced Usage
Playing with search spaces
It is possible to choose the search space for each cryptographic parameters. For example, here we constrain the glwe dimension to be equal to 1:
./optimizer --max-glwe-dim 1
Generating reference files
Some of our tests are comparing parameters found by previous version of torus-optimizer against
the parameters found by the current state of torus-optimizer.
To generate those references, you must be in v0-parameters directory. For the default AP you can do:
cargo run --release --bin v0-parameters-by-level
and for the new WoP-PBS AP
cargo run --release --bin v0-parameters-by-level -- --wop-pbs
The reference files will be written in the ref/ folder.