mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
fc9b2e03e1
Auto-fixes from the paper accuracy swarm: unambiguous build-breakers, broken \ref/\cite/\input targets, and prose typos. Substantive accuracy findings (dates, contradictory numbers, LP numbering) reported separately for review.
63 lines
3.2 KiB
TeX
63 lines
3.2 KiB
TeX
\section{Background}
|
|
|
|
\label{sec:background}
|
|
%%==========================================================================
|
|
|
|
\subsection{Lux Network Architecture}
|
|
|
|
Lux employs a three-chain primary network:
|
|
\begin{itemize}[leftmargin=1.5em]
|
|
\item \textbf{P-Chain} (Platform Chain): tracks validator sets, manages staking, creates
|
|
appchains.
|
|
\item \textbf{X-Chain} (Exchange Chain): UTXO-based chain for asset issuance and trading.
|
|
\item \textbf{C-Chain} (Contract Chain): EVM-compatible chain for smart contracts.
|
|
\end{itemize}
|
|
|
|
Validators post a minimum 2,000 LUX stake on the P-Chain and run all three primary chains.
|
|
Appchain validation is opt-in: a primary validator may additionally validate any subset of
|
|
registered appchains by running the appchain's VM and advertising participation on the P-Chain.
|
|
Historically, appchain validators received no direct remuneration from appchains, creating a
|
|
mismatch between the security provided and the incentive to provide it~\cite{lux2020platform}.
|
|
|
|
\subsection{Beacon Consensus}
|
|
|
|
Lux's Beacon consensus achieves probabilistic finality in $\mathcal{O}(\log n)$ rounds
|
|
under the honest-majority assumption, with sub-second finality observed in practice. The
|
|
key property relevant to restaking is that conflicting transactions are identified and
|
|
rejected rapidly: any equivocating validator (one who votes for two conflicting blocks) can
|
|
be detected within one consensus epoch. This property enables efficient slashing without
|
|
requiring extended unbonding periods~\cite{rocket2019wave}.
|
|
|
|
\subsection{EigenLayer and Prior Work}
|
|
|
|
EigenLayer~\cite{eigen2023restaking} pioneered restaking on Ethereum, enabling ETH stakers
|
|
to opt into securing additional Actively Validated Services via delegation to operators who
|
|
run AVS-specific software. Key characteristics of EigenLayer:
|
|
|
|
\begin{itemize}[leftmargin=1.5em]
|
|
\item Ethereum-native: operates through beacon chain withdrawal credentials and LST
|
|
(Liquid Staking Token) deposits.
|
|
\item Slashing is coordinated through EigenLayer's \texttt{SlasherManager} contract.
|
|
\item AVSs register their slashing conditions as smart contracts.
|
|
\item Operators choose which AVSs to serve; restakers delegate to operators.
|
|
\end{itemize}
|
|
|
|
Limitations include: long unbonding periods (7 days on Ethereum), high gas costs for
|
|
slashing coordination, and the absence of native primitives for appchain-level security
|
|
(since Ethereum has no equivalent to Lux appchains).
|
|
|
|
\subsection{Related Work}
|
|
|
|
Cosmos Hub's Interchain Security (ICS)~\cite{cosmos2022ics} provides a different approach:
|
|
consumer chains lease the entire validator set of the Hub rather than individual validators.
|
|
This is simpler but less flexible, requiring all Hub validators to participate. Polkadot's
|
|
shared security model~\cite{wood2016polkadot} assigns parachains to relay-chain validator
|
|
subsets through an auction mechanism. Neither model enables the granular, operator-chosen
|
|
service selection that LRP provides.
|
|
|
|
Babylon~\cite{babylon2023bitcoin} explores restaking Bitcoin security to PoS chains via
|
|
UTXO timestamping. While complementary, it addresses a different threat model (long-range
|
|
attacks) rather than Byzantine fault tolerance in execution environments.
|
|
|
|
%%==========================================================================
|