mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
08440f23dd
Drops the named-competitor scaffold's TFHE-rs and Concrete (both Zama) entries from
lux-fhe-benchmarks and the matching bibliography. The CGGI academic citation for the
underlying TFHE scheme (Chillotti et al., Journal of Cryptology 2020) is kept — it's
the scheme we implement, not a library we depend on. Competitor coverage retained:
TFHE-CGGI reference, OpenFHE, VeloFHE/OpenFHE-GPU, Microsoft SEAL.
Other touch-ups in the same sweep:
lux-fhe-runtime/08-related-work.tex — rewrites "Concrete (Zama)" subsection
as a generic "FHE compiler stacks" one.
lux-fhe-smart-contracts main + 03 — positive framing ("on luxfi/lattice")
instead of negative ("not tfhe-rs, not Zama").
legacy-md/FOLLOW-UPS-2026-05-12.md — drops Zama tfhe-rs from the bench harness
plan; OpenFHE + Lux-FHE only.
Lux FHE is native: luxfi/fhe + luxfi/lattice, with optional C++ / GPU (Metal+CUDA) /
FPGA acceleration paths. No tfhe-rs, no Zama, no external library wrapping.
80 lines
3.4 KiB
TeX
80 lines
3.4 KiB
TeX
\section{Related work}
|
|
\label{sec:fhe-related-work}
|
|
|
|
\subsection{TFHE base}
|
|
|
|
Chillotti, Gama, Georgieva, and Izabach\`ene introduced TFHE in 2016,
|
|
with the canonical "fast bootstrapping" construction in TFHE-Library
|
|
(\texttt{github.com/tfhe/tfhe}). Subsequent work --- Joye \&
|
|
Paillier's polynomial-fold variants, the LMKCDEY 2023 optimizations
|
|
adopted by OpenFHE STD128 --- extended the gate-evaluation pipeline.
|
|
Lux FHE adopts the LMKCDEY-aligned $\mathsf{PN9QP28\_STD128}$
|
|
parameter set explicitly so apples-to-apples comparison with OpenFHE
|
|
is possible; \emph{lux-fhe-benchmarks} reports the head-to-head
|
|
numbers.
|
|
|
|
\subsection{OpenFHE}
|
|
|
|
OpenFHE (\texttt{openfhe.org}) is the C++ FHE library spun out of
|
|
PALISADE. Its scope --- BFV, BGV, CKKS, and FHEW/TFHE --- is broader
|
|
than Lux FHE-C++; Lux FHE-C++ is intentionally TFHE-only on the
|
|
production path. OpenFHE is the standard reference for cross-runtime
|
|
performance comparison; \emph{lux-fhe-benchmarks} reports the
|
|
parameters and head-to-head numbers. Where OpenFHE supports a
|
|
parameter set we ship as well, the Lux FHE-Go reference is byte-equal
|
|
to OpenFHE's output up to format-encoding details (we report the
|
|
encoding diff in \emph{lux-fhe-benchmarks}).
|
|
|
|
\subsection{Microsoft SEAL}
|
|
|
|
SEAL (\texttt{github.com/microsoft/SEAL}) implements BFV and CKKS,
|
|
not TFHE. Its design --- C++ with no GPU backend, single-runtime ---
|
|
is the inverse of the Lux dual-runtime split. We do not target SEAL
|
|
parameter sets directly.
|
|
|
|
\subsection{HEAAN}
|
|
|
|
HEAAN is the original CKKS reference. Lux FHE-Go does not implement
|
|
CKKS today; the encrypted-arithmetic targets for blockchain
|
|
workloads (confidential ERC-20, encrypted comparison) are TFHE-native
|
|
and CKKS would be a regression in noise behavior.
|
|
|
|
\subsection{FHE compiler stacks}
|
|
|
|
Compiler-first FHE stacks lift Python / C-like circuits to
|
|
FHE-native gate sequences. Lux FHE-Compiler (planned, see LP-167
|
|
roadmap) targets that same problem from the Go side; the dual-runtime
|
|
split (gate-level interpreter + compiled circuit path) is unique
|
|
to Lux.
|
|
|
|
\subsection{NIST IR 8214C}
|
|
|
|
The NIST Threshold Cryptography Project's IR 8214C (Multi-Party
|
|
Threshold Cryptography) is the framing reference for Lux FHE's
|
|
threshold keygen and decryption (LP-019, LP-076). Lux FHE
|
|
parameter-set lambda targets are chosen to exceed NIST's
|
|
category-1 floor under both classical and quantum adversaries; see
|
|
\texttt{proofs/fhe/parameter-security.tex}.
|
|
|
|
\subsection{What's distinctive}
|
|
|
|
\paragraph{Dual runtime.} The Go reference + C++/GPU production
|
|
split is unique to Lux. OpenFHE / SEAL / HEAAN ship a single C++
|
|
runtime; Concrete ships a single Rust + LLVM stack. Lux's
|
|
discipline --- the Go runtime is the oracle, the C++ runtime is
|
|
the throughput, the KAT corpus enforces equivalence --- is the
|
|
operational invariant the rest of the stack rests on.
|
|
|
|
\paragraph{Consensus binding.} OpenFHE / SEAL / HEAAN / Concrete
|
|
do not bind FHE result roots into a consensus transcript --- they
|
|
have no consensus to bind to. Lux's $\mathsf{nebula\_fhe\_root}$ is
|
|
the bridge: FHE results enter Quasar finality through the Pulsar
|
|
+ ML-DSA (+ optional Beam) lanes, with replay protection via the
|
|
HashSuiteID + KeyEraID + Generation bindings.
|
|
|
|
\paragraph{Post-quantum from the bottom up.} FHE security rests on
|
|
LWE / RLWE; both are post-quantum-hard. The threshold keygen path
|
|
is post-quantum (Pulsar). The finality wrapping (HorizonCertificate)
|
|
is post-quantum (Pulsar Pulse + ML-DSA). The Lux stack is PQ end
|
|
to end; Lux FHE inherits that.
|