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.
59 lines
2.5 KiB
TeX
59 lines
2.5 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{Regulated Access}
|
|
\label{sec:regulated}
|
|
|
|
Certain data---personal health information, financial records, legal
|
|
documents---is subject to regulatory requirements that mandate specific
|
|
access controls. Threshold cryptography enables compliance without
|
|
centralized key escrow.
|
|
|
|
\subsection{Compliance-Gated Reveal}
|
|
|
|
\begin{definition}[Compliance Gate]
|
|
A compliance gate $\mathcal{C} = (\pi, t_c, \{C_1, \ldots, C_{n_c}\})$
|
|
requires that a data reveal operation satisfies policy $\pi$ (evaluated
|
|
via TFHE on the T-Chain) and is co-signed by $t_c$ of $n_c$ compliance
|
|
officers. The reveal is a threshold decryption operation:
|
|
\begin{equation}
|
|
\mathsf{Reveal}(d) = \begin{cases}
|
|
\mathsf{ThreshDec}(t + t_c, \{s_i\}_{i \in S \cup C}) & \text{if } \mathsf{Eval}(\pi) = 1 \\
|
|
\perp & \text{otherwise}
|
|
\end{cases}
|
|
\end{equation}
|
|
where $S$ is the set of user-authorized shares and $C$ is the set of
|
|
compliance officer shares.
|
|
\end{definition}
|
|
|
|
The UX presents this as: ``Viewing this record requires compliance
|
|
approval. A compliance officer has been notified.'' The compliance
|
|
officer sees: ``[User] requests access to [record type]. Reason:
|
|
[stated reason]. [Approve] [Deny].'' No cryptographic ceremony is
|
|
visible to either party.
|
|
|
|
\subsection{Audit Trail}
|
|
|
|
Every compliance-gated reveal produces an on-chain receipt recording:
|
|
\begin{itemize}
|
|
\item Who requested the reveal (user DID)
|
|
\item Who approved (compliance officer DIDs)
|
|
\item When the reveal occurred (block timestamp)
|
|
\item What was revealed (hash of the decrypted data, not the data itself)
|
|
\item Why (the policy $\pi$ that was satisfied)
|
|
\end{itemize}
|
|
|
|
This provides a tamper-evident audit trail that satisfies regulatory
|
|
requirements (HIPAA access logs, GDPR data access records, SOC~2 access
|
|
controls) without requiring a centralized audit service.
|
|
|