mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
abf99d05fc
Restructured from flat .tex/.pdf files into per-paper subdirectories. Added Antje Worring as co-author on all papers. Synced PDFs to pdfs/ for download site.
37 lines
2.1 KiB
TeX
37 lines
2.1 KiB
TeX
\section{Cross-Chain Attack Surfaces}
|
|
|
|
|
|
\subsection{Class 1: Bridge Exploits (Message Forgery)}
|
|
|
|
An attacker forges a cross-chain message claiming that assets were deposited on chain $A$, and redeems them on chain $B$.
|
|
|
|
\textbf{Historical examples:} Ronin (\$625M, compromised validator keys), Wormhole (\$325M, signature verification bypass), Nomad (\$190M, initialization bug).
|
|
|
|
\textbf{Lux mitigation:} Warp messages are signed by the BLS aggregate of the source chain's validator set. Verification on the destination chain checks the BLS aggregate against the P-Chain validator set. Forging a message requires corrupting $>1/3$ of the primary network validators.
|
|
|
|
\subsection{Class 2: Replay Attacks}
|
|
|
|
A valid message from chain $A$ to chain $B$ is replayed on chain $B'$, or the same message is submitted twice on chain $B$.
|
|
|
|
\textbf{Lux mitigation:} Five replay protection mechanisms (detailed in Section~\ref{sec:replay}):
|
|
\begin{enumerate}[leftmargin=2em]
|
|
\item Domain separator (chain ID + network ID)
|
|
\item Per-chain monotonic nonces
|
|
\item Message expiry timestamps
|
|
\item Destination chain binding
|
|
\item Consumed-message bitmap
|
|
\end{enumerate}
|
|
|
|
\subsection{Class 3: Finality Mismatch}
|
|
|
|
Chain $A$ finalizes a deposit. The message is relayed to chain $B$. Chain $A$ then reorganizes, reverting the deposit. The assets now exist on chain $B$ but not on chain $A$.
|
|
|
|
\textbf{Lux mitigation:} Warp messages are only emitted after epoch finality (triple-proof). Since triple-proof finality is absolute (no reorganization possible after epoch confirmation), this attack is eliminated by construction.
|
|
|
|
\subsection{Class 4: Validator Set Desynchronization}
|
|
|
|
Chain $B$ uses a stale validator set to verify messages from chain $A$. An attacker who controlled validators that have since been removed can forge messages using old keys.
|
|
|
|
\textbf{Lux mitigation:} Warp message verification on the destination chain queries the P-Chain for the current validator set at the message's epoch. Validator set updates propagate within one epoch (1 second). Messages referencing epochs older than a configurable staleness window (default: 60 epochs = 1 minute) are rejected.
|
|
|