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]>
77 lines
3.3 KiB
TeX
77 lines
3.3 KiB
TeX
|
|
%% ===================================================================
|
|
%% LP-134 canonical naming (2025-12-15):
|
|
%% Per LP-134 (Lux Chain Topology), M-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)
|
|
%% M-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{UX Interaction Patterns}
|
|
\label{sec:ux}
|
|
|
|
The following patterns define how threshold operations are presented to
|
|
users across all the product experiences described above.
|
|
|
|
\subsection{Notification-Driven Approval}
|
|
|
|
Threshold operations are initiated by one party and completed by others
|
|
via push notifications. The initiator sees a pending state (``Waiting for
|
|
2 more approvals''). Approvers see an actionable notification (``[User]
|
|
requests your approval for [action]. [Approve] [Deny]'').
|
|
|
|
Design rules:
|
|
\begin{enumerate}
|
|
\item Notifications must describe the action in plain language, never
|
|
in cryptographic terms.
|
|
\item The approval action is a single tap/click, not a multi-step process.
|
|
\item The approver can inspect details (amount, recipient, document name)
|
|
before approving.
|
|
\item Rejection is always available and requires no justification (though
|
|
the system may prompt for one).
|
|
\end{enumerate}
|
|
|
|
\subsection{Progress Indicators}
|
|
|
|
Users waiting for threshold completion see a progress indicator:
|
|
``2 of 3 approvals received. Waiting for Alice or Bob.'' The indicator
|
|
updates in real time as approvals arrive. This maps the abstract concept
|
|
of ``quorum assembly'' to the familiar concept of ``waiting for responses.''
|
|
|
|
\subsection{Delegation}
|
|
|
|
When an approver is unavailable, they can delegate their approval
|
|
capability to a substitute for a bounded time period. The UX presents
|
|
this as: ``You have a pending approval request but marked yourself as
|
|
away. Would you like to delegate to [substitute]? They will be able to
|
|
approve on your behalf until [date].''
|
|
|
|
Delegation is implemented as a threshold key share re-encryption: the
|
|
approver's share $s_i$ is re-encrypted under the delegate's public key
|
|
via a proxy re-encryption scheme \cite{blaze1998divertible}, without
|
|
revealing $s_i$ to any intermediary. The delegation expires automatically
|
|
(the re-encryption key has a time-bounded validity enforced by the
|
|
M-Chain).
|
|
|
|
\subsection{Recovery UX}
|
|
|
|
The recovery experience avoids all cryptographic terminology:
|
|
|
|
\begin{enumerate}
|
|
\item User on new device: ``I lost access to my account.''
|
|
\item System: ``We'll contact your recovery contacts. 3 of 5 need to
|
|
confirm it's you.''
|
|
\item Each guardian: ``[User] says they lost access. Can you confirm
|
|
this is really them? You may want to call them to verify.
|
|
[Confirm] [This Isn't Them]''
|
|
\item When 3 confirm: ``Your account has been restored to this device.''
|
|
\end{enumerate}
|
|
|
|
The user never learns what Shamir secret sharing is. They experience
|
|
a social verification process that happens to be cryptographically
|
|
enforced.
|
|
|