Files
papers/lux-app-architecture/sections/01-introduction.tex
zeekay cb3b572a9c papers: M/F/Z-Chain canonical naming per LP-134
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.
2026-05-05 16:28:50 -07:00

62 lines
3.4 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{Introduction}
\label{sec:intro}
% ============================================================================
The dominant crypto thesis of 2017--2023 treated the blockchain as a universal
substrate: database, server, and compute engine collapsed into one replicated
state machine. Every document, every message, every user action was supposed to
live on-chain. The result was systems that were simultaneously too slow for
applications, too expensive for storage, and too public for privacy.
The failure was architectural. Blockchains are excellent trust planes---they
produce globally verifiable proofs about who controls what keys, what policies
govern those keys, and which state transitions have been authorized. They are
terrible data planes. Storing a user's notes, messages, or collaborative documents
on a replicated ledger is the wrong abstraction at every level: cost per byte,
latency per read, privacy per query.
The local-first software movement~\cite{kleppmann2019} identified the correct
alternative: applications that work offline, store data locally, and synchronize
through conflict-free replicated data types (CRDTs). But local-first software
without a trust layer has no answer for identity, key recovery, capability
delegation, or auditability. It produces isolated islands of encrypted state
with no shared coordination.
Web5 is the synthesis. The data plane is local: encrypted SQLite vaults per
principal, synchronized as ciphertext via CRDTs, decrypted only on the owner's
device. The trust plane is Lux: identity roots on I-Chain, key policies on
K-Chain, threshold reveals on T-Chain, MPC signing on M-Chain, and audit anchors
on the primary network. Providers---relay operators, storage hosts, recovery
agents, compute markets---are optional, replaceable, and never data owners.
The Capsule is the unit that makes this concrete. This paper defines it formally,
proves its properties, and specifies the three classes of applications it enables.
\paragraph{Contributions.}
\begin{enumerate}[label=(\roman*),nosep]
\item Formal definition of the Capsule as a seven-tuple (Section~\ref{sec:model}).
\item Classification of three application classes with distinct trust requirements
(Section~\ref{sec:apps}).
\item Specification of the Lux trust kernel across four purpose-built chains
(Section~\ref{sec:trust}).
\item Security analysis under the post-quantum threat model with tiered
cryptographic guarantees (Section~\ref{sec:pq}).
\item Design of agent capsules---AI agents as sovereign processes with auditable
memory and bounded capabilities (Section~\ref{sec:agents}).
\item Honest accounting of unsolved problems (Section~\ref{sec:unsolved}).
\end{enumerate}
% ============================================================================