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]>
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)
|
|
%% T-Chain is REMOVED entirely; teleport is B-Chain (bridgevm, LP-6000). No teleportvm.
|
|
%% Where this paper says "F-Chain MPC" / "F-Chain threshold governance" /
|
|
%% "F-Chain TFHE" / "F-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 F-Chain:
|
|
\[
|
|
Q = (2, 2, \{\mathsf{did}_A, \mathsf{did}_B\}, \mathsf{AND}, \mathsf{timeout})
|
|
\]
|
|
Both capsules submit their encrypted votes. The F-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}
|
|
|
|
%% ===================================================================
|