mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
0cb5a945ca
Genericize every reference to the white-label tenant tenant to 'a regulated exchange partner' / 'regulated-partner' across the ZAP-wire migration paper (workspace + service counts + ownership), the avalanche-diff translation wallet/stack lists, the sovereign-keys regulated-model tables, the block-STM workload label, and the 4.0-launch resale/deployment lines. Hard brand strings (the tenant, the tenant, tenant EVM/DEX) were already absent on origin/main; this removes the lingering company name. Legitimate DeFi 'liquidity' terms and the Lux Liquidity Protocol (LP-310) are untouched.
64 lines
2.3 KiB
TeX
64 lines
2.3 KiB
TeX
\section{MPC for Threshold Control}
|
|
|
|
\label{sec:mpc}
|
|
|
|
\subsection{Same Primitives, Different Trust}
|
|
|
|
The sovereign model uses the same threshold signing protocols as the
|
|
regulated model (CGGMP21 for ECDSA, FROST for EdDSA). The difference
|
|
is who controls the signers:
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\small
|
|
\begin{tabular}{@{}lll@{}}
|
|
\toprule
|
|
\textbf{Property} & \textbf{Regulated (exchange partner)} & \textbf{Sovereign (Lux)} \\
|
|
\midrule
|
|
Shard holders & Operator + HSM + cold & User + trusted parties \\
|
|
Threshold & 2-of-3 (operator is 1) & User-defined $t$-of-$n$ \\
|
|
Operator shards & 1 (below threshold) & 0 \\
|
|
Recovery & Operator cold storage & Social recovery \\
|
|
Key generation & Operator-initiated DKG & User-initiated DKG \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\caption{MPC trust model comparison.}
|
|
\label{tab:mpc-comparison}
|
|
\end{table}
|
|
|
|
\subsection{User-Controlled Signers}
|
|
|
|
In the sovereign model, the user initiates distributed key generation (DKG)
|
|
and designates the signer set. Typical configurations:
|
|
\begin{itemize}[nosep]
|
|
\item \textbf{Personal}: 2-of-3 with user device, backup device, and a
|
|
recovery share held by a trusted contact.
|
|
\item \textbf{Organization}: 3-of-5 with board members as shard holders.
|
|
\item \textbf{DAO}: $m$-of-$n$ with on-chain governance controlling
|
|
signer rotation.
|
|
\end{itemize}
|
|
|
|
The provider holds zero shards. The provider cannot sign, cannot veto,
|
|
and cannot participate in signing.
|
|
|
|
\subsection{Social Recovery}
|
|
|
|
If the user loses their device, recovery uses threshold shares distributed
|
|
to trusted parties at vault creation time. The recovery protocol:
|
|
|
|
\begin{enumerate}[nosep]
|
|
\item User contacts $t$ of their $n$ designated recovery parties.
|
|
\item Each party authenticates the user (out-of-band: video call, in-person,
|
|
pre-shared secret).
|
|
\item Each party submits their recovery share to the new device.
|
|
\item The new device reconstructs the root key from $t$ shares.
|
|
\item The root key decrypts the vault DEK; all data is accessible.
|
|
\end{enumerate}
|
|
|
|
No operator involvement. No ``forgot password'' flow that bypasses
|
|
encryption. If the user cannot reach $t$ recovery parties, the data is
|
|
permanently inaccessible. This is the intended behavior: data sovereignty
|
|
means the user bears the responsibility.
|
|
|
|
% ======================================================================
|