papers/lux-threshold-ux/sections/02-threshold-primitives-on-lux.tex

%% ===================================================================
%% LP-134 canonical naming (2025-12-15):
%% Per LP-134 (Lux Chain Topology), T-Chain has been split into:
%%   M-Chain — MPC ceremonies for bridge custody of EXTERNAL wallets
%%             (CGGMP21, FROST, Pulsar-general)
%%   F-Chain — FHE compute + TFHE bootstrap-key generation (encrypted EVM)
%% The legacy name "T-Chain" is retained ONLY for `teleportvm` (LP-6332).
%% Where this paper says "T-Chain MPC" / "T-Chain threshold governance" /
%% "T-Chain TFHE" / "T-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
%% ===================================================================

\section{Threshold Primitives on Lux}
\label{sec:primitives}

Lux Network provides threshold cryptography through two dedicated chains:

\begin{enumerate}
    \item \textbf{T-Chain (Threshold Chain).} Manages threshold policies,
    TFHE-encrypted policy evaluation, and CKKS confidential compute. The
    T-Chain stores encrypted policy conditions and evaluates them
    homomorphically, producing a binary approve/deny decision without
    revealing the policy inputs to any single party.

    \item \textbf{M-Chain (MPC Chain).} Executes multi-party threshold
    signatures via FROST (for Schnorr/Ed25519) and CGGMP21 (for ECDSA).
    The M-Chain coordinates distributed key generation (DKG), signing
    rounds, and key refresh without any party learning the full private key.
\end{enumerate}

\subsection{FROST Threshold Signatures}

FROST \cite{komlo2020frost} is a round-optimized Schnorr threshold signature
scheme. In the Lux deployment, FROST operates as follows:

\begin{definition}[FROST Configuration]
A FROST configuration $\Phi = (t, n, \{P_1, \ldots, P_n\}, \mathsf{pk})$
consists of a threshold $t$, a total participant count $n$, a set of
participants $P_i$ each holding a key share $s_i$, and the aggregate
public key $\mathsf{pk}$. A valid signature requires the cooperation
of any $t$ of the $n$ participants.
\end{definition}

The signing protocol proceeds in two rounds:

\begin{algorithm}[H]
\caption{FROST Threshold Signing (simplified)}
\label{alg:frost}
\begin{algorithmic}[1]
\Require Message $m$, threshold $t$, participants $\{P_{i_1}, \ldots, P_{i_t}\}$
\State \textbf{Round 1 (Commitment):} Each $P_{i_j}$ generates nonce pair $(d_{i_j}, e_{i_j})$ and broadcasts commitments $(D_{i_j}, E_{i_j})$
\State \textbf{Round 2 (Response):} Each $P_{i_j}$ computes partial signature $z_{i_j}$ using Lagrange interpolation coefficients
\State \textbf{Aggregation:} Coordinator computes $\sigma = (R, z)$ where $R = \prod D_{i_j}^{\rho_{i_j}} \cdot E_{i_j}$ and $z = \sum z_{i_j}$
\State \Return $\sigma$ (standard Schnorr signature, verifiable with $\mathsf{pk}$)
\end{algorithmic}
\end{algorithm}

The output is an ordinary Schnorr signature. No verifier can distinguish
a FROST threshold signature from a single-signer Schnorr signature. This
property is essential for Threshold UX: the cryptographic machinery is
invisible to anyone not participating in the signing ceremony.

\subsection{TFHE Policy Evaluation}

The T-Chain evaluates access control policies over encrypted inputs using
TFHE (Torus Fully Homomorphic Encryption) \cite{chillotti2020tfhe}. A
policy $\pi$ is a Boolean circuit that takes encrypted attributes as input
and produces an encrypted Boolean decision:

\begin{equation}
    \mathsf{Eval}(\pi, \mathsf{Enc}(a_1), \ldots, \mathsf{Enc}(a_k)) = \mathsf{Enc}(\pi(a_1, \ldots, a_k))
\end{equation}

The decision is threshold-decrypted by $t$-of-$n$ T-Chain validators,
revealing only the binary result (approve/deny) without exposing the
input attributes or the policy logic.