mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-02 11:39:52 +00:00
zeekay
cb3b572a9c
Add LP-134 canonical naming banner to 46 LaTeX papers that reference T-Chain in MPC/FHE context. Banner clarifies the M-Chain (MPC ceremonies for external-wallet bridge custody) and F-Chain (FHE compute) split. LP-020 quasar-consensus paper already correctly describes the M/F-Chain split and is unmodified.
75 lines
3.8 KiB
TeX
75 lines
3.8 KiB
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{Chain-Level Conflict Rules}
|
|
|
|
\label{sec:conflict}
|
|
%% ============================================================================
|
|
|
|
Every VM in the Lux fleet exposes a single predicate,
|
|
$\mathsf{conflicts}(v_1, v_2) \in \{\mathsf{true},\mathsf{false}\}$,
|
|
over pairs of vertices. The predicate must be \emph{symmetric} and
|
|
\emph{computable from the vertex batch alone}. Table~\ref{tab:conflict}
|
|
summarises the per-chain rule.
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\small
|
|
\begin{tabular}{lllll}
|
|
\toprule
|
|
\textbf{Chain} & \textbf{Symbol} & \textbf{Engine} & \textbf{Conflict key set} & \textbf{Source} \\
|
|
\midrule
|
|
C-Chain (EVM) & C & DAG & $R(v) \cup W(v) \subseteq \mathsf{StorageKey}$ & Block-STM \\
|
|
D-Chain (DEX) & D & DAG & $\{(base,quote,side,id)\} \subseteq \mathsf{OrderKey}$ & orderbook \\
|
|
X-Chain (UTXO) & X & DAG & $\{\mathsf{txo}_i\} \subseteq \mathsf{UTXO}$ & UTXO inputs \\
|
|
Z-Chain (ZK-UTXO) & Z & DAG & $\{\mathsf{null}_i\} \subseteq \mathsf{Nullifier}$ & nullifier reveal \\
|
|
Q-Chain (PQ) & Q & DAG+Quasar & $\{\mathsf{stamp}_i\}$ & PQ attestation \\
|
|
A-Chain (AI) & A & DAG & $\{\mathsf{jobID}_i\}$ & job graph \\
|
|
O-Chain (Oracle) & O & DAG & $\{(\mathsf{feed},\mathsf{round})\}$ & feed rounds \\
|
|
R-Chain (Relay) & R & DAG & $\{(\mathsf{dstChain},\mathsf{nonce})\}$ & relay nonce \\
|
|
S-Chain (ServiceNode) & S & DAG & $\{(\mathsf{node},\mathsf{epoch})\}$ & service epoch \\
|
|
\midrule
|
|
P-Chain (Platform) & P & Linear & ordered & validator set \\
|
|
B-Chain (Bridge) & B & Linear & ordered & ceremony steps \\
|
|
T-Chain (Threshold) & T & Linear & ordered & FROST rounds \\
|
|
M-Chain (MPC) & M & Sharded-linear & per-wallet linear & CGGMP21 rounds \\
|
|
K-Chain (Keys) & K & Linear & ordered & key rotation \\
|
|
I-Chain (Identity) & I & Linear & ordered & identity updates \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\caption{Per-chain conflict rule. The first block operates under the DAG
|
|
engine with native parallel finality. The second block retains linear
|
|
ordering where the state machine requires total order (validator registry,
|
|
cryptographic ceremonies, identity updates).}
|
|
\label{tab:conflict}
|
|
\end{table}
|
|
|
|
We say a pair of vertices \emph{commutes} iff it does not conflict.
|
|
|
|
\begin{definition}[Conflict DAG]
|
|
A \emph{conflict DAG} $D = (V, E, \mathsf{conflicts})$ is a directed acyclic
|
|
graph whose vertices are VM-specific transaction batches, whose edges are
|
|
causal parent relationships, and whose conflict predicate satisfies the
|
|
\emph{Siblings-Commute invariant}: for every pair of vertices $v_1, v_2$
|
|
with $v_1 \not\preceq v_2$ and $v_2 \not\preceq v_1$ in the DAG partial
|
|
order, $\mathsf{conflicts}(v_1, v_2)$ is false.
|
|
\end{definition}
|
|
|
|
The Siblings-Commute invariant is enforced constructively by the VM's
|
|
$\mathsf{BuildVertex}$: when forming a new vertex the builder scans the
|
|
current \emph{frontier} (set of rank-maximal accepted vertices) and refuses
|
|
any batch whose conflict key set overlaps a frontier sibling. This is an
|
|
$O(|\text{frontier}| \cdot |\text{keys}|)$ bitmap intersection; on GPU it
|
|
is a single threadgroup-reduce kernel.
|
|
|
|
%% ============================================================================
|