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.
77 lines
3.2 KiB
TeX
77 lines
3.2 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{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
|
|
T-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.
|
|
|