papers/lux-warp-messaging/sections/07-validator-set-tracking.tex

\section{Validator Set Tracking}
\label{sec:tracking}

\subsection{Cross-Appchain Validator Awareness}

Destination appchains must know the source appchain's validator set to verify proofs. LWM propagates validator set updates as special warp messages:

\begin{definition}[Validator Set Update (VSU)]
\begin{equation}
    \mathcal{M}_{\text{VSU}} = (\mathsf{src}, \mathsf{broadcast}, e{+}1, \Delta\mathcal{V}_{e \to e+1}, \infty, 0)
\end{equation}
where $\Delta\mathcal{V}$ is the set difference (added/removed validators with keys and weights), signed by $\geq 2/3$ of epoch-$e$ validators.
\end{definition}

The genesis validator set for each appchain is embedded in the primary network's state, establishing the root of trust.

\subsection{Efficient Representation via Merkle Commitments}

For large validator sets, we commit to the set via a Merkle tree:
\begin{equation}
    \mathsf{VRoot}_e = \mathsf{MerkleRoot}\bigl(\{(\mathsf{pk}_i, w_i)\}_{i \in \mathcal{V}_e}\bigr)
\end{equation}

Warp proofs then include Merkle inclusion proofs for each signer. This trades proof size (additional $\log n \cdot 32$ bytes per signer) for destination storage ($O(1)$ per tracked appchain instead of $O(n)$).

\begin{table}[H]
\centering
\caption{Destination storage: full set vs.\ Merkle commitment.}
\label{tab:storage}
\begin{tabular}{lrr}
\toprule
\textbf{Method} & \textbf{Per-Appchain Storage} & \textbf{Proof Overhead} \\
\midrule
Full validator set & $128n$ bytes & 0 \\
Merkle commitment & 40 bytes & $32 \lceil\log_2 n\rceil \cdot |\mathcal{Q}|$ bytes \\
\bottomrule
\end{tabular}
\end{table}