mirror of
https://github.com/luxfhe/torus.git
synced 2026-10-30 17:07:26 +00:00
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.2 KiB
3.2 KiB
Inventory Matching System
Introduction
This tutorial implements two variants of the Inventory Matching System described in this paper:
prime-match.py implements the classical protocol, while prime-match-semi-honest.py follows the semi-honest protocol.
The principle is as follows: a bank has a list of orders, and a client has another list of orders. Orders are either Sell or Buy, followed by an asset. We want to apply the matching between the orders, without the parties to know what are each other orders.
A simple example is
Bank Orders:
Sell 10 of C
Buy 47 of A
Sell 31 of D
Client Orders:
Sell 50 of A
Sell 24 of B
Buy 18 of D
The corresponding resolution is
Bank Orders:
Sell 0 of C
Buy 47 of A
Sell 18 of D
Client Orders:
Sell 47 of A
Sell 24 of B
Buy 18 of D
Executing the classic protocol
We can run our prime-match.py to perform the computations: FHE Simulation is done in the clear to build expected results, while FHE is the real FHE computation. Our execution here was done on an hpc7a machine on AWS, with Torus v2.8.1, in about 3 seconds for 50 transactions on 10 symbols.
$ python prime-match.py
Key generation took: 10.746 seconds
Sample Input:
Bank Orders:
Buy 17 of E
Buy 30 of F
Sell 6 of D
Sell 34 of J
Buy 30 of C
Sell 54 of I
Buy 25 of G
Sell 8 of B
Sell 21 of H
Buy 24 of A
Client Orders:
Buy 56 of F
Buy 32 of A
Sell 44 of H
Buy 39 of J
Sell 50 of C
FHE Simulation:
Bank Orders:
Buy 0 of E
Buy 0 of F
Sell 0 of D
Sell 34 of J
Buy 30 of C
Sell 0 of I
Buy 0 of G
Sell 0 of B
Sell 0 of H
Buy 0 of A
Client Orders:
Buy 0 of F
Buy 0 of A
Sell 0 of H
Buy 34 of J
Sell 30 of C
FHE:
Bank Orders:
Buy 0 of E
Buy 0 of F
Sell 0 of D
Sell 34 of J
Buy 30 of C
Sell 0 of I
Buy 0 of G
Sell 0 of B
Sell 0 of H
Buy 0 of A
Client Orders:
Buy 0 of F
Buy 0 of A
Sell 0 of H
Buy 34 of J
Sell 30 of C
Complexity was: 158500926100.000
Nb of transactions: 50
Nb of Symbols: 10
Execution took: 3.237 seconds, ie 0.065 seconds per transaction
Executing the semi honest protocol
We have executed the semi-honest protocol, still on an hpc7a machine on AWS, with Torus v2.8.1, in 1 second for 20 transactions on 10 symbols.
$ python prime-match-semi-honest.py
Key generation took: 9.606 seconds
FHE Simulation:
Result Orders:
0 0 -> 0
23 20 -> 20
0 0 -> 0
7 27 -> 7
0 0 -> 0
0 0 -> 0
0 0 -> 0
41 13 -> 13
23 24 -> 23
0 0 -> 0
11 4 -> 4
0 0 -> 0
45 3 -> 3
0 0 -> 0
4 49 -> 4
33 31 -> 31
24 15 -> 15
0 0 -> 0
0 0 -> 0
2 23 -> 2
FHE:
Result Orders:
0 0 -> 0
23 20 -> 20
0 0 -> 0
7 27 -> 7
0 0 -> 0
0 0 -> 0
0 0 -> 0
41 13 -> 13
23 24 -> 23
0 0 -> 0
11 4 -> 4
0 0 -> 0
45 3 -> 3
0 0 -> 0
4 49 -> 4
33 31 -> 31
24 15 -> 15
0 0 -> 0
0 0 -> 0
2 23 -> 2
Complexity was: 23066687400.000
Quantities in [1, 50]
Nb of transactions: 20
Nb of Symbols: 10
Execution took: 1.011 seconds, ie 0.051 seconds per transaction