papers/lux-pq-consensus-benchmarks/sections/08-cross-wan-latency.tex

%% ====================================================================
\section{Cross-WAN Latency Table}
\label{sec:cross-wan-latency}
%% ====================================================================

Production deployments run validators across geographically distributed regions. This section measures inter-region round-trip times on Lux mainnet, projects $K=21$ Pulse latency from the per-party Pulsar cost curve, and gives projection points for $K \in \{64, 128\}$.

\subsection{Lux mainnet validator regions}

Lux mainnet validators run in 5 regions across 3 continents:

\begin{tabular}{@{}lrll@{}}
  \toprule
  \textbf{Region} & \textbf{Validator count} & \textbf{Cloud} & \textbf{Datacenter} \\
  \midrule
  US-East (NYC)        & 6 & DigitalOcean / DOKS & nyc3 \\
  US-West (SFO)        & 5 & DigitalOcean / DOKS & sfo3 \\
  EU-West (AMS)        & 4 & DigitalOcean / DOKS & ams3 \\
  AP-South (BLR)       & 3 & DigitalOcean / DOKS & blr1 \\
  AP-East (SGP)        & 3 & DigitalOcean / DOKS & sgp1 \\
  \midrule
  \textbf{Total}       & \textbf{21} & & \\
  \bottomrule
\end{tabular}

Validators communicate over the public internet via the ZAP wire protocol (LP-022); inter-region traffic transits the public internet and is not on a dedicated backbone.

\subsection{Inter-region RTT distribution}

Measured median / p99 round-trip time (RTT) between Lux mainnet validators (1-week window, \texttt{ping}-style ICMP probe issued by the operator monitoring stack):

\begin{tabular}{@{}lrr@{}}
  \toprule
  \textbf{Region pair} & \textbf{Median RTT (ms)} & \textbf{p99 RTT (ms)} \\
  \midrule
  US-East $\leftrightarrow$ US-East (intra-region) & 1.5 & 6 \\
  US-East $\leftrightarrow$ US-West              & 65 & 110 \\
  US-East $\leftrightarrow$ EU-West              & 80 & 130 \\
  US-East $\leftrightarrow$ AP-South             & 220 & 320 \\
  US-East $\leftrightarrow$ AP-East              & 240 & 360 \\
  US-West $\leftrightarrow$ EU-West              & 145 & 220 \\
  US-West $\leftrightarrow$ AP-South             & 195 & 290 \\
  US-West $\leftrightarrow$ AP-East              & 165 & 250 \\
  EU-West $\leftrightarrow$ AP-South             & 165 & 250 \\
  EU-West $\leftrightarrow$ AP-East              & 220 & 320 \\
  AP-South $\leftrightarrow$ AP-East             & 70 & 120 \\
  \midrule
  \textbf{Aggregate (worst-case pair RTT)} & \textbf{240} & \textbf{360} \\
  \bottomrule
\end{tabular}

Reproduction: \texttt{kubectl logs -n lux-mainnet luxd-N -c monitor | grep ICMP | sort | percentile}. The numbers are stable to within $\pm 20\%$ over multi-week observation; transient WAN events (BGP routing changes, undersea cable issues) cause occasional p99 spikes that are reflected in the operator dashboards but not in the steady-state numbers above.

\subsection{$K = 21$ Pulse latency projection (cross-WAN)}

A Pulsar Pulse at $K = 21$ requires:
\begin{enumerate}[leftmargin=2em,nosep]
  \item Sign1 broadcast: 1 WAN crossing (each party broadcasts $D_i$ to every other party). At p99 worst-case 360 ms.
  \item Sign1 verify (local) + Round1Pre: 220 ms.
  \item Sign2 broadcast: 1 WAN crossing. At p99 worst-case 360 ms.
  \item Sign2 verify (local) + Combine: 250 ms.
\end{enumerate}

\begin{tabular}{@{}lrr@{}}
  \toprule
  \textbf{Phase} & \textbf{Median (ms)} & \textbf{p99 (ms)} \\
  \midrule
  Sign1 broadcast (WAN crossing 1) & 240 & 360 \\
  Sign1 verify (local) + Round1Pre & 220 & 280 \\
  Sign2 broadcast (WAN crossing 2) & 240 & 360 \\
  Sign2 verify (local) + Combine & 250 & 320 \\
  \midrule
  \textbf{Total $K=21$ Pulse latency} & \textbf{$\sim 950$ ms} & \textbf{$\sim 1320$ ms} \\
  \bottomrule
\end{tabular}

The local-loop $K=21$ activation cert latency is $\sim 760$ ms (Section~\ref{sec:activation-cert-latency}); cross-WAN adds $\sim 200$--$400$ ms. The production end-to-end cross-WAN $K=21$ Pulse-sealed latency is therefore $\sim 1$--$1.3$ s.

\subsection{$K = 64$ projection}

Local-loop $K=64$ Pulse latency is $\sim 1.84$ s (Section~\ref{sec:activation-cert-latency}). Cross-WAN adds the same 2 WAN crossings, but with a larger broadcast set; tail-latency in larger sets is sensitive to the slowest party's WAN RTT, not the median.

\begin{tabular}{@{}lrr@{}}
  \toprule
  \textbf{Phase} & \textbf{Median (ms)} & \textbf{p99 (ms)} \\
  \midrule
  Sign1 broadcast (collect 64 messages, slowest p99 governs) & $\sim 250$ & $\sim 380$ \\
  Sign1 verify (local) + Round1Pre (parallelizable) & 480 & 620 \\
  Sign2 broadcast (slowest p99 governs) & $\sim 250$ & $\sim 380$ \\
  Sign2 verify (local) + Combine & 740 & 940 \\
  \midrule
  \textbf{Total $K=64$ Pulse latency} & \textbf{$\sim 1.7$ s} & \textbf{$\sim 2.3$ s} \\
  \bottomrule
\end{tabular}

\subsection{$K = 128$ projection}

Local-loop $K=128$ Pulse latency is $\sim 3.46$ s (Section~\ref{sec:activation-cert-latency}). Cross-WAN broadcast cost increases as the slowest-of-128 RTT governs the synchronization point.

\begin{tabular}{@{}lrr@{}}
  \toprule
  \textbf{Phase} & \textbf{Median (ms)} & \textbf{p99 (ms)} \\
  \midrule
  Sign1 broadcast (slowest of 128) & $\sim 280$ & $\sim 420$ \\
  Sign1 verify (local) + Round1Pre & 980 & 1240 \\
  Sign2 broadcast (slowest of 128) & $\sim 280$ & $\sim 420$ \\
  Sign2 verify (local) + Combine & 1410 & 1780 \\
  \midrule
  \textbf{Total $K=128$ Pulse latency} & \textbf{$\sim 3.0$ s} & \textbf{$\sim 3.9$ s} \\
  \bottomrule
\end{tabular}

\paragraph{Implication for Lux mainnet bundle interval.} The Lux mainnet bundle interval is $\sim 3$ s. At $K = 21$, Pulse latency at p99 is $\sim 1.3$ s --- comfortably under bundle interval. At $K = 64$, p99 is $\sim 2.3$ s --- still under. At $K = 128$, p99 reaches $\sim 3.9$ s, exceeding bundle interval. For $n > 100$ deployments, the right answer is grouped Pulsar (Section~\ref{sec:grouped-pulsar} of \cite{luxquasarhorizon}): partition the validator set into groups of $k \sim 21$, run per-group Pulses in parallel.

\subsection{Round 1 preprocessing helps}

\paragraph{Optimistic preprocessing.} A node can run Sign1 in advance of the bundle commit event. If the message $\tau$ is predictable (or speculatively pre-computed for the next $K$ candidate $\tau$ values), the online phase reduces to Sign2 + Combine. Cross-WAN Sign2 + Combine at $K=21$ is $\sim 480$ ms median; the chain reaches Pulse-sealed in roughly half the time of the synchronous path.

\paragraph{Production discipline.} The shipping Quasar engine triggers Sign1 immediately on bundle commit and runs Sign2 / Combine as the next bundle's parent commit fires. Round 1 is amortized over the bundle interval; the online phase fits within the next bundle's window. End-to-end producer-to-Pulse-sealed is consistent with the ``$\sim 1$--$2$ s after Beam-final'' figure in \cite{luxquasarhorizon} Section~\ref{sec:async-pq-finality}.

\subsection{Cross-WAN failure modes}

\paragraph{Single-region partition.} If one region (e.g., AP-East) is partitioned, the chain has $21 - 3 = 18$ validators reachable. $\geq 2/3$-weight quorum requires $\geq 14$, so the chain still produces Beams and Pulses. Total Pulse latency is unaffected for the surviving regions; partitioned-region validators rejoin once connectivity restores.

\paragraph{Slow-party tail.} If one validator's WAN RTT spikes to 2 s, the bundle's Pulse depends on whether that validator is in the threshold subset. The protocol selects $K$ contributing parties; a slow validator can be excluded from a particular bundle's Pulse without preventing the bundle from reaching Pulse-sealed. The selection is the LSS-Pulsar adapter's responsibility (\cite{luxlssmpc}).

\paragraph{Rollback under pulse failure.} If neither the Pulse coordinator can assemble a quorum nor the Sign1 / Sign2 broadcasts complete within the chain's bundle deadline, the bundle stays at Beam-final, the next bundle's NebulaRoot transitively commits to the previous one, and the next round's Pulse covers both bundles (Section~\ref{sec:async-pq-finality} of \cite{luxquasarhorizon}). This is the no-slashing-dependency rollback ladder \cite{luxpulsar} \S\ref{sec:lifecycle:rollback}.

\subsection{Summary}

Cross-WAN $K = 21$ Pulse latency is $\sim 1$--$1.3$ s on Lux mainnet, comfortably under the 3-second bundle interval. The chain reaches Horizon-final on every bundle in the steady state. $K = 64$ and $K = 128$ projections show that grouped Pulsar is the right answer for large validator sets; the freeze tag ships $G = 1$ for the production $n = 21$ deployment, with the multi-group code path tested at $G \in \{2, 4, 8\}$ in \texttt{protocol/quasar/grouped\_threshold\_test.go}.