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.
65 lines
3.0 KiB
TeX
65 lines
3.0 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{Cross-Capsule Coordination}
|
|
\label{sec:cross-capsule}
|
|
%% ===================================================================
|
|
|
|
Two capsules $\mathcal{C}_A$ and $\mathcal{C}_B$ interact through the trust
|
|
kernel without either capsule exposing plaintext to the other or to the chain.
|
|
|
|
\subsection{Key Exchange}
|
|
|
|
Capsule $\mathcal{C}_A$ retrieves $\mathcal{C}_B$'s public encapsulation key
|
|
$\mathsf{ek}_B$ from the K-Chain, verifies it is active and satisfies
|
|
$\mathcal{C}_A$'s trust policy, and performs ML-KEM encapsulation:
|
|
\[
|
|
(c, K) \gets \mathsf{ML\text{-}KEM.Encaps}(\mathsf{ek}_B)
|
|
\]
|
|
The ciphertext $c$ is delivered to $\mathcal{C}_B$ off-chain. The K-Chain
|
|
records a \textsc{CapGranted} receipt noting that $\mathcal{C}_A$ was granted
|
|
encapsulation rights for $\mathcal{C}_B$'s key. The shared secret $K$ is used
|
|
to derive a symmetric session key for subsequent encrypted communication.
|
|
|
|
\subsection{Capability Delegation}
|
|
|
|
$\mathcal{C}_A$ may delegate a capability to $\mathcal{C}_B$ by submitting a
|
|
\textsc{GrantCap} transaction to the K-Chain:
|
|
\[
|
|
\textsc{GrantCap}(\mathsf{key}_A, \mathsf{did}_B, \mathsf{cap}, \mathsf{expiry})
|
|
\]
|
|
This creates a verifiable, time-bounded delegation chain. $\mathcal{C}_B$ can
|
|
prove to any verifier that it holds capability $\mathsf{cap}$ over
|
|
$\mathsf{key}_A$ by presenting the \textsc{CapGranted} receipt.
|
|
|
|
\subsection{Threshold Approval}
|
|
|
|
For operations requiring mutual consent (e.g., a joint contract signing),
|
|
$\mathcal{C}_A$ and $\mathcal{C}_B$ create a 2-of-2 quorum on the T-Chain:
|
|
\[
|
|
Q = (2, 2, \{\mathsf{did}_A, \mathsf{did}_B\}, \mathsf{AND}, \mathsf{timeout})
|
|
\]
|
|
Both capsules submit their encrypted votes. The T-Chain evaluates the AND
|
|
predicate. If both approve, a \textsc{GovernanceReceipt} is emitted that
|
|
authorizes the subsequent action (e.g., M-Chain signing, K-Chain rotation).
|
|
|
|
\begin{theorem}[Cross-Capsule Confidentiality]\label{thm:cross-capsule}
|
|
In the cross-capsule coordination protocol, the trust kernel learns:
|
|
(i)~the identities of the participating capsules, (ii)~the type of
|
|
coordination (key exchange, delegation, threshold approval), and
|
|
(iii)~the boolean outcome. The trust kernel does not learn the plaintext
|
|
of any data exchanged between capsules, any attribute values used in
|
|
ZK proofs, or any vote values in TFHE-encrypted quorum evaluations.
|
|
\end{theorem}
|
|
|
|
%% ===================================================================
|