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]>
57 lines
2.7 KiB
TeX
57 lines
2.7 KiB
TeX
\section{Background}
|
|
|
|
\label{sec:background}
|
|
%%==========================================================================
|
|
|
|
\subsection{Lux Appchain Architecture}
|
|
|
|
A Lux appchain consists of:
|
|
\begin{itemize}[leftmargin=1.5em]
|
|
\item A subset of Primary Network validators who additionally validate the appchain;
|
|
\item A custom virtual machine (VM) specifying the state transition function;
|
|
\item An independent consensus instance (Quasar or custom);
|
|
\item Optional: native gas token, custom fee structure, validator admission policy.
|
|
\end{itemize}
|
|
|
|
Appchains are registered on the P-Chain via a \texttt{CreateAppchain} transaction, which
|
|
requires a one-time fee of 1 LUX (as of this writing). Validators opt into appchain
|
|
validation via \texttt{AddAppchainValidator} transactions. Critically, appchain validators
|
|
are not required to use LUX as their gas token; they may denominate fees in any ERC-20
|
|
token or in the appchain's native currency.
|
|
|
|
LUX is the Primary Network staking and gas asset. Its protocol hard cap is
|
|
2 trillion LUX (the genesis \texttt{SupplyCap}); circulating supply grows along
|
|
the emission schedule of the Lux Tokenomics companion paper and remains far
|
|
within this cap.
|
|
|
|
\subsection{Economic Primitives}
|
|
|
|
Let $\mathcal{N}$ denote the set of Primary Network validators with staking weights
|
|
$\{w_v\}_{v \in \mathcal{N}}$ and total stake $W = \sum_v w_v$. The annual Primary Network
|
|
staking yield for validator $v$ is:
|
|
\[
|
|
y_v = \frac{\text{AnnualPrimaryReward}(v)}{w_v \cdot P_{\text{LUX}}},
|
|
\]
|
|
where $P_{\text{LUX}}$ is the LUX price in USD. This yield represents the \emph{opportunity
|
|
cost} that appchain incentives must exceed to attract validators.
|
|
|
|
\subsection{Related Work}
|
|
|
|
Cosmos Zone economics~\cite{kwon2016cosmos} are the closest analogue: application-specific
|
|
chains with sovereign validator sets secured by ATOM-denominated staking. Key differences
|
|
from Lux appchains include: Cosmos chains maintain independent validator sets (no sharing),
|
|
IBC is the interoperability layer (versus Lux's native cross-chain messaging), and ATOM
|
|
inflation subsidizes security rather than fee revenue.
|
|
|
|
Ethereum Layer 2 economics~\cite{konstantopoulos2021optimism} address a different
|
|
problem---reducing mainnet congestion through off-chain execution with on-chain validity
|
|
guarantees---but share the challenge of bootstrapping sequencer economics without
|
|
centralization.
|
|
|
|
Polkadot parachain auctions~\cite{wood2016polkadot} provide an interesting comparison:
|
|
parachains bid for relay-chain security through DOT bond auctions, creating a market-driven
|
|
mechanism for security allocation. LRP appchains instead pay validators directly, which is
|
|
more flexible but requires more explicit incentive design.
|
|
|
|
%%==========================================================================
|