mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
cb3b572a9c
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.
63 lines
2.7 KiB
TeX
63 lines
2.7 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{Implementation}
|
|
\label{sec:implementation}
|
|
|
|
The Agent Capsule framework is implemented as a Base SDK library integrated with the Lux trust kernel.
|
|
|
|
\subsection{Base SDK Integration}
|
|
|
|
The Base SDK (Hanzo Base) provides the local runtime for Agent Capsules:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{Encrypted SQLite.} The vault uses SQLCipher with AES-256-GCM, keyed from the DID private key via HKDF.
|
|
\item \textbf{CRDT engine.} A built-in CRDT engine handles LWW-Register and OR-Set synchronization over authenticated TLS channels.
|
|
\item \textbf{Capability store.} Capability tokens are stored in a local credential wallet with automatic expiry pruning.
|
|
\item \textbf{Budget client.} A C-Chain light client tracks the capsule's balance and enforces local spend limits before submitting transactions.
|
|
\end{itemize}
|
|
|
|
\subsection{Lux Trust Kernel Integration}
|
|
|
|
The capsule interacts with four Lux chains:
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{Agent Capsule integration with Lux chains.}
|
|
\label{tab:chains}
|
|
\begin{tabular}{llp{6.5cm}}
|
|
\toprule
|
|
\textbf{Chain} & \textbf{Role} & \textbf{Agent Capsule Usage} \\
|
|
\midrule
|
|
P-Chain & Validator sets & Capsule registration, execution environment attestation \\
|
|
C-Chain & Smart contracts & Budget accounts, settlement, capability exchange \\
|
|
T-Chain & Threshold crypto & Threshold spend approval, FHE key management, recovery \\
|
|
I-Chain & Identity & DID anchoring, credential issuance, revocation registry \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsection{MCP Protocol Integration}
|
|
|
|
Tool use follows the Model Context Protocol (MCP)~\cite{anthropic2024mcp}. Each tool invocation is mediated by the capability system:
|
|
|
|
\begin{enumerate}
|
|
\item The agent requests tool $T$ via its MCP endpoint.
|
|
\item The MCP server verifies that the agent holds a valid \texttt{invoke} capability for $T$.
|
|
\item The tool executes and returns results.
|
|
\item An action receipt is generated and stored in the vault.
|
|
\item The cost of the tool invocation is deducted from the budget.
|
|
\end{enumerate}
|
|
|
|
This ensures that every tool use is authorized, audited, and accounted for.
|
|
|