papers/lux-economics/sections/08-elastic-appchain-scaling.tex

\section{Elastic Appchain Scaling}

\label{sec:elastic}
%%==========================================================================

\subsection{Motivation}

Fixed validator set sizes are suboptimal: small appchains with low utilization pay for
over-provisioned security, while rapidly growing appchains may have validator sets too
small to handle peak load or maintain Byzantine fault tolerance at required thresholds.

\subsection{Demand-Responsive Validator Scaling}

Define the \emph{load metric} $\Lambda_s(t)$ as the smoothed transaction volume of
appchain $s$:
\[
  \Lambda_s(t) = (1-\alpha) \cdot \Lambda_s(t-1) + \alpha \cdot \text{TxCount}(s, t),
\]
where $\alpha = 0.1$ (exponential moving average). The target validator count is:
\begin{equation}
  n_s^*(t) = n_s^{\min} + \left\lfloor \frac{\Lambda_s(t)}{\Lambda_{\text{threshold}}} \right\rfloor \cdot \Delta n,
  \label{eq:elastic}
\end{equation}

where $n_s^{\min}$ is the minimum validator count for BFT (typically 5), $\Lambda_{\text{threshold}}$
is the load per validator threshold, and $\Delta n$ is the scaling step size.

\subsection{Admission and Ejection}

When $n_s^*(t) > n_s(t)$ (demand exceeds supply), the appchain emits an \emph{expansion
signal} on the AVS marketplace (see the Lux Restaking Protocol companion paper).
Eligible Primary Network validators who meet the appchain's criteria are admitted in order
of reputation score until $n_s(t) = n_s^*(t)$.

When $n_s^*(t) < n_s(t)$ (oversupply), the appchain initiates a \emph{graceful ejection}
process: validators with the lowest reputation scores are given 24 hours' notice and
then removed from the active set. Their unbonding periods begin at removal.

\subsection{Security Under Elastic Scaling}

\begin{theorem}[BFT Preservation Under Elastic Scaling]
If the minimum validator count $n_s^{\min} \geq 3f+1$ where $f$ is the maximum tolerated
faulty validators, and new validators are admitted only after passing the reputation
threshold $\rho_{\min}$, then BFT safety is maintained throughout scaling transitions.
\end{theorem}

\begin{proof}
At any point in time, the active validator set has cardinality $n_s(t) \geq n_s^{\min}$.
Since $n_s^{\min} \geq 3f+1$, the Beacon consensus protocol tolerates up to $f$
Byzantine validators. New entrants undergo a probationary period where they observe
consensus without voting (preventing Sybil injection during scaling events). After the
probationary period, they join the voting set only if $n_s(t) + 1$ still satisfies the
BFT constraint.
\end{proof}

\subsection{Scaling Performance}

We simulate elastic scaling for a gaming appchain experiencing a viral event (10$\times$
traffic spike) and a DeFi appchain during a market crash (0.5$\times$ traffic):

\begin{table}[H]
\centering
\caption{Elastic Scaling Response Times}
\label{tab:elastic_perf}
\begin{tabular}{lrrrr}
\toprule
\textbf{Scenario} & \textbf{Traffic Change} & \textbf{$\Delta n$} & \textbf{Response Time} & \textbf{Downtime} \\
\midrule
Gaming spike & $+900\%$ & $+15$ validators & 4.2 minutes & 0 \\
Gaming normalization & $-800\%$ & $-14$ validators & 27.3 hours (graceful) & 0 \\
DeFi crash & $-50\%$ & $-3$ validators & 27.3 hours (graceful) & 0 \\
DeFi recovery & $+120\%$ & $+4$ validators & 6.1 minutes & 0 \\
\bottomrule
\end{tabular}
\end{table}

Scale-up events are fast (minutes, limited by P-Chain transaction finality and validator
onboarding). Scale-down events are slow by design (24-hour graceful ejection), ensuring
validators receive fair notice and preventing rapid shrinkage that would reduce security.

%%==========================================================================