mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-03 05:07:46 +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.
64 lines
3.2 KiB
TeX
64 lines
3.2 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{Agent Capabilities}
|
|
\label{sec:capabilities}
|
|
|
|
The capability model governs what an agent is permitted to do. Capabilities are fine-grained, composable, and enforced at the protocol level.
|
|
|
|
\begin{definition}[Capability Token]
|
|
A capability token $\kappa = (r, s, t_0, t_1, \sigma)$ comprises:
|
|
\begin{itemize}
|
|
\item $r \in \{\texttt{read}, \texttt{write}, \texttt{sign}, \texttt{spend}, \texttt{delegate}, \texttt{invoke}\}$: the right,
|
|
\item $s$: the scope (a resource identifier or pattern),
|
|
\item $[t_0, t_1]$: the validity window,
|
|
\item $\sigma$: the issuer's signature over $(r, s, t_0, t_1)$.
|
|
\end{itemize}
|
|
\end{definition}
|
|
|
|
\subsection{Capability Classes}
|
|
|
|
We define six capability classes:
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{Agent capability classes and their scopes.}
|
|
\label{tab:capabilities}
|
|
\begin{tabular}{llp{6cm}}
|
|
\toprule
|
|
\textbf{Right} & \textbf{Example Scope} & \textbf{Description} \\
|
|
\midrule
|
|
\texttt{read} & \texttt{vault://agent/\{id\}/*} & Read data from a specified vault path \\
|
|
\texttt{write} & \texttt{vault://agent/\{id\}/memory/*} & Write to the agent's memory namespace \\
|
|
\texttt{sign} & \texttt{chain://c-chain/tx/*} & Sign transactions on a specific chain \\
|
|
\texttt{spend} & \texttt{budget://\{id\}/max:100LUX} & Spend up to a specified amount \\
|
|
\texttt{delegate} & \texttt{cap://\{id\}/depth:2} & Delegate capabilities up to a depth \\
|
|
\texttt{invoke} & \texttt{mcp://tool/web-search} & Invoke a specific MCP tool \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsection{Threshold Approval}
|
|
|
|
High-value actions require threshold approval rather than unilateral agent execution. A threshold policy $\pi = (n, k, \mathcal{A})$ specifies that $k$ out of $n$ authorized parties in set $\mathcal{A}$ must co-sign the action. Threshold signing is performed via the T-Chain's distributed key generation (DKG) and threshold signature scheme~\cite{gennaro2020threshold}:
|
|
|
|
\begin{equation}\label{eq:threshold}
|
|
\sigma_{\text{threshold}} = \text{TSS.Combine}\big(\{\sigma_i\}_{i \in S}, |S| \geq k\big)
|
|
\end{equation}
|
|
|
|
This prevents a compromised agent from unilaterally executing catastrophic actions (e.g., draining its entire budget, signing high-value transactions, delegating all capabilities).
|
|
|
|
\subsection{Time-Bounded Grants}
|
|
|
|
All capabilities expire. There are no permanent grants. The maximum validity window $t_1 - t_0$ is bounded by a protocol parameter $\Delta_{\max}$ (default: 30 days). Renewal requires explicit re-issuance by the granting principal, forcing periodic review of agent permissions.
|
|
|