papers/lux-trust-kernel/sections/01-introduction.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{Introduction}
\label{sec:intro}
%% ===================================================================

Blockchains are routinely misapplied as general-purpose databases. This conflation
creates systems that are simultaneously too expensive for data storage and too
opaque for trust verification. The root cause is a failure to distinguish between
two orthogonal concerns: \emph{data management} (storage, indexing, query) and
\emph{trust management} (identity, authorization, coordination, audit).

\begin{definition}[Trust Kernel]\label{def:trust-kernel}
A trust kernel $\mathcal{K}$ is a replicated state machine that provides exactly
four services to application capsules:
\begin{enumerate}[label=(\alph*)]
    \item \textbf{Identity}: globally-unique, self-sovereign identifiers bound to
          cryptographic key material;
    \item \textbf{Key Policy}: lifecycle management (registration, rotation,
          revocation) with enforceable policy constraints;
    \item \textbf{Threshold Governance}: quorum-controlled state transitions
          requiring $t$-of-$n$ authorization;
    \item \textbf{Receipts}: tamper-evident, append-only records of every
          trust-relevant state transition.
\end{enumerate}
\end{definition}

The trust kernel stores no application data. It stores \emph{commitments to decisions
about data}: who created it, who may access it, under what conditions, and when those
conditions were evaluated. This separation is not merely architectural preference---it
is a security boundary. Data that never touches the chain cannot leak from the chain.

\subsection{What Local Vaults Cannot Provide}

An encrypted local vault (a capsule, as defined in \cite{lux-capsule-architecture})
provides strong confidentiality and integrity for data at rest. However, a vault alone
cannot provide:

\begin{enumerate}[label=(\roman*)]
    \item \textbf{Global identity}: a vault can generate keypairs, but cannot prove
          uniqueness or non-repudiation to a third party without a shared root of trust;
    \item \textbf{Cross-party coordination}: two vaults cannot agree on a shared secret,
          delegate capabilities, or approve a joint action without a coordination layer
          that both trust;
    \item \textbf{Settlement finality}: a vault can record local state, but cannot
          prove to an external verifier that a state transition occurred at a specific
          time and was not subsequently reversed.
\end{enumerate}

The trust kernel fills exactly these gaps. It is the minimum viable chain: the smallest
on-chain footprint that makes sovereign applications composable.

\subsection{Contribution}

This paper makes the following contributions:

\begin{enumerate}
    \item We formalize the trust kernel abstraction and prove it sufficient for
          sovereign application composition (Section~\ref{sec:intro}).
    \item We specify the K-Chain key registry with ML-KEM wrapping, rotation
          policy, and revocation receipts (Section~\ref{sec:kchain}).
    \item We define T-Chain threshold governance with TFHE policy evaluation and
          CKKS confidential compute (Section~\ref{sec:tchain}).
    \item We describe M-Chain MPC signing via FROST and CGGMP21
          (Section~\ref{sec:mchain}).
    \item We specify the I-Chain decentralized identity layer with ZK selective
          disclosure (Section~\ref{sec:ichain}).
    \item We define the receipt anchoring protocol and prove its
          tamper-evidence (Section~\ref{sec:receipts}).
    \item We show how the trust kernel enables provider switching without data
          loss (Section~\ref{sec:provider}).
    \item We formalize cross-capsule coordination through the trust kernel
          (Section~\ref{sec:cross-capsule}).
    \item We present the security model with formal trust assumptions and PQ
          migration path (Section~\ref{sec:security}).
    \item We reference mechanized Lean~4 proofs for all critical protocols
          (Section~\ref{sec:verification}).
\end{enumerate}

%% ===================================================================