papers/lux-app-architecture/sections/03-three-classes-of-applications.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{Three Classes of Applications}
\label{sec:apps}
% ============================================================================

The Capsule model supports three distinct application classes, each with
different trust assumptions and cryptographic requirements.

\subsection{Class I: Local-First Private Applications}\label{sec:class1}

The simplest class. The vault is the entire application backend. All reads and
writes happen locally. Sync is peer-to-peer or through an encrypted relay.
The chain is used only for identity and audit anchors.

\paragraph{Examples.} Note-taking apps, personal finance trackers, password
managers, local AI assistants, private journals, health records.

\paragraph{Trust model.} The principal trusts only their own device and key
material. Providers see ciphertext. The chain sees only anchor hashes and
capability metadata.

\begin{definition}[Class I Application]\label{def:class1}
A Class I application is a pair $(f, \mathcal{C})$ where $f$ is a deterministic
function $f: V \times \mathsf{Input} \to V \times \mathsf{Output}$ that executes
entirely on the principal's device, reading from and writing to the local vault $V$.
Sync propagates encrypted CRDT operations; no provider or peer sees plaintext.
\end{definition}

\paragraph{Provider portability.} A Class I app can switch sync providers by
updating $\Sigma$. The new provider receives the encrypted CRDT log. No
re-encryption is necessary because providers never held the key.

\subsection{Class II: Threshold Applications}\label{sec:class2}

Applications requiring multi-party authorization. The vault may be shared across
principals, with operations gated by threshold policies on K-Chain and secret
reveals on M-Chain.

\paragraph{Examples.} Treasury management (3-of-5 approval for transfers),
organizational admin recovery, secrets management (reveal API key to authorized
member), multi-party document signing, escrow release.

\paragraph{Trust model.} No single principal controls the operation. A quorum
of $t$-of-$n$ participants must authorize via M-Chain. The chain enforces the
threshold---providers cannot bypass it.

\begin{definition}[Class II Application]\label{def:class2}
A Class II application is a triple $(g, \mathcal{C}_1, \ldots, \mathcal{C}_n)$
where $g$ is a function that executes only when $t$-of-$n$ capsule owners
produce valid authorization proofs on M-Chain. The function $g$ may read from
multiple vaults (with delegated capabilities) and write results back to
designated vaults.
\end{definition}

\paragraph{Threshold mechanics.} The authorization proof is a threshold signature
aggregated on M-Chain using the protocol specified in~\cite{lux-mchain-mpc}.
Each participant signs a \textit{proposal hash} containing the operation
description, target vault identifiers, and an expiration timestamp. The chain
verifies the threshold and emits an authorization receipt before $g$ executes.

\subsection{Class III: Confidential Compute Applications}\label{sec:class3}

Applications where computation must occur on encrypted data without any party
(including the compute provider) seeing plaintext. This class uses fully
homomorphic encryption (FHE) or trusted execution environments (TEEs).

\paragraph{Examples.} Private AI inference (run a model on encrypted user data),
encrypted analytics (aggregate statistics without seeing individual records),
sealed-bid auctions, private credit scoring, confidential voting.

\paragraph{Trust model.} The compute provider executes on ciphertext. Results
are encrypted under the requesting principal's key. For FHE, trust is purely
cryptographic. For TEE, trust additionally assumes hardware attestation
integrity.

\begin{definition}[Class III Application]\label{def:class3}
A Class III application is a tuple $(h, \mathcal{C}, \mathsf{CP})$ where
$h$ is a function compiled to an FHE circuit or TEE enclave, $\mathcal{C}$ is
the requesting capsule, and $\mathsf{CP}$ is a confidential compute provider.
The provider evaluates $h$ on $\mathsf{Enc}(x)$ where $x$ is extracted from $V$
and encrypted under a scheme supporting homomorphic evaluation. The result
$\mathsf{Enc}(h(x))$ is returned to the principal for local decryption.
\end{definition}

\paragraph{FHE integration.} Class III applications use the TFHE scheme specified
in~\cite{lux-tfhe} for boolean circuits and CKKS for approximate arithmetic.
Key generation and decryption happen inside the capsule. The FHE evaluation key
(public) is sent to the compute provider. The secret key never leaves the vault.

\subsection{Application Class Summary}

\begin{table}[H]
\centering
\caption{Comparison of application classes.}
\label{tab:classes}
\begin{tabular}{@{}llll@{}}
\toprule
& \textbf{Class I} & \textbf{Class II} & \textbf{Class III} \\
\midrule
Compute location & Local device & Local + chain & Provider (encrypted) \\
Chain usage & Anchor, identity & Threshold enforce & Compute verification \\
Provider sees & Ciphertext only & Ciphertext only & Ciphertext + eval key \\
Crypto required & AES + ML-KEM & + threshold sigs & + FHE or TEE \\
Latency & Sub-ms & Seconds (chain) & Seconds--minutes \\
\bottomrule
\end{tabular}
\end{table}

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