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]>
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), F-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)
|
|
%% F-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{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 F-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.
|
|
|