mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekayandHanzo Dev
178febad68
Every rendered "T-Chain" / "ThresholdVM" / "teleportvm" reference across the paper corpus is rewritten to the correct canonical chain by concern: threshold signing / MPC / bridge custody / key recovery -> M-Chain (MVM); FHE / encrypted compute / threshold decryption -> F-Chain (FVM); teleport / cross-chain messaging -> B-Chain (bridgevm); consensus Pulsar stays Q-Chain. Section lux-trust-kernel/03-t-chain-threshold-governance.tex renamed -> 03-f-chain-encrypted-policy.tex (with \input + xref fixes). Braided "T-Chain" sections split by concern (M vs F). Only lp-020's chain-separation rationale and the shared lux/chains/thresholdvm library path retain the name, to record the removal. All changed papers rebuilt (pdflatex, rc=0, no undefined refs). §09 of lux-dao-governance-framework reframed: fabricated "production deployment" metrics ($50M/$240k/$12M, survey %s, "as of Oct 2024") relabeled as illustrative design configurations with no invented replacements; reality noted (DAO treasury is a 1/1 Safe); conclusion echo + one "first production" overclaim softened. This commit also captures concurrent corpus workstreams on the same tree. Co-authored-by: Hanzo Dev <[email protected]>
78 lines
3.6 KiB
TeX
78 lines
3.6 KiB
TeX
|
|
%% ===================================================================
|
|
%% LP-134 canonical naming (2025-12-15):
|
|
%% Per LP-134 (Lux Chain Topology), F-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)
|
|
%% F-Chain is REMOVED entirely; teleport is B-Chain (bridgevm, LP-6000). No teleportvm.
|
|
%% Where this paper says "F-Chain MPC" / "F-Chain threshold governance" /
|
|
%% "F-Chain TFHE" / "F-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{F-Chain (Threshold Chain).} Manages threshold policies,
|
|
TFHE-encrypted policy evaluation, and CKKS confidential compute. The
|
|
F-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 F-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$ F-Chain validators,
|
|
revealing only the binary result (approve/deny) without exposing the
|
|
input attributes or the policy logic.
|
|
|