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]>
73 lines
3.4 KiB
TeX
73 lines
3.4 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 "M-Chain MPC" / "M-Chain threshold governance" /
|
|
%% "M-Chain TFHE" / "M-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
|
|
%% ===================================================================
|
|
|
|
\section{Provider Model}
|
|
\label{sec:providers}
|
|
% ============================================================================
|
|
|
|
Providers are participants in the Web5 ecosystem that offer services to capsule
|
|
owners. They are not data owners. They never hold decryption keys. They are
|
|
replaceable.
|
|
|
|
\subsection{Provider Roles}
|
|
|
|
\begin{definition}[Provider]\label{def:provider}
|
|
A provider is a registered entity on I-Chain offering one or more services from
|
|
the set $\{\mathsf{relay}, \mathsf{storage}, \mathsf{gateway}, \mathsf{recovery},
|
|
\mathsf{compute}, \mathsf{index}\}$, with service quality commitments published
|
|
on-chain and enforced by staking.
|
|
\end{definition}
|
|
|
|
\begin{itemize}[nosep]
|
|
\item \textbf{Relay}: Forwards encrypted CRDT operations between peers.
|
|
Sees ciphertext. Provides availability, not confidentiality.
|
|
\item \textbf{Storage}: Hosts encrypted vault snapshots and WAL segments.
|
|
Provides durability. Subject to proof-of-storage challenges.
|
|
\item \textbf{Gateway}: HTTP/WebSocket endpoint for client applications.
|
|
Handles authentication (DID-based), rate limiting, and protocol
|
|
translation. Does not decrypt.
|
|
\item \textbf{Recovery}: Holds encrypted key shares for threshold recovery.
|
|
Cannot reconstruct alone (requires $t$-of-$n$ on M-Chain).
|
|
\item \textbf{Compute}: Executes FHE circuits or TEE enclaves for Class III
|
|
applications. Receives evaluation keys and ciphertext. Returns encrypted
|
|
results.
|
|
\item \textbf{Index}: Maintains searchable indexes over encrypted metadata
|
|
(using techniques like order-preserving encryption or searchable
|
|
symmetric encryption) for query acceleration.
|
|
\end{itemize}
|
|
|
|
\subsection{Provider Economics}
|
|
|
|
Providers stake LUX on the primary network. Capsule owners pay providers in LUX
|
|
for services consumed. Payments are per-operation (relay fees), per-byte-month
|
|
(storage fees), or per-circuit-evaluation (compute fees). Service level
|
|
agreements are on-chain; slashing occurs for downtime or data loss verified
|
|
by proof-of-storage audits. The staking and fee mechanics follow the framework
|
|
in~\cite{lux-tokenomics}.
|
|
|
|
\subsection{Provider Switching}
|
|
|
|
Switching providers is a four-step process:
|
|
\begin{enumerate}[nosep]
|
|
\item Update $\Sigma$ to include the new provider.
|
|
\item The new provider receives the encrypted vault snapshot and catches up
|
|
on the CRDT log from an existing peer or the old provider.
|
|
\item Verify replication by comparing checkpoint hashes.
|
|
\item Update $\Sigma$ to exclude the old provider.
|
|
\end{enumerate}
|
|
|
|
No key rotation is required. No data re-encryption is required. The principal
|
|
does not need to be online during the transfer---any peer in $\Sigma$ can serve
|
|
the encrypted state.
|
|
|
|
% ============================================================================
|