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]>
62 lines
3.4 KiB
TeX
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)
|
|
%% T-Chain is REMOVED entirely; teleport is B-Chain (bridgevm, LP-6000). No teleportvm.
|
|
%% Where this paper says "M-Chain MPC" / "M-Chain threshold governance" /
|
|
%% "M-Chain TFHE" / "M-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 M-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}
|
|
|
|
% ============================================================================
|