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]>
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)
|
|
%% T-Chain is REMOVED entirely; teleport is B-Chain (bridgevm, LP-6000). No teleportvm.
|
|
%% 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 \\
|
|
M-Chain (FROST) & M & Linear & ordered & FROST rounds \\
|
|
M-Chain (CGGMP21) & 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.
|
|
|
|
%% ============================================================================
|