papers/lux-warp-v2/sections/08-related-work.tex

%% ====================================================================
\section{Related Work}
\label{sec:warp-related-work}
%% ====================================================================

We compare Warp 2.0 to four cross-chain messaging protocols: Chainlink CCIP, Wormhole, IBC, and LayerZero. The structural lens is the cryptographic basis for source-chain finality: each protocol's source-finality story has a different shape, and Warp 2.0's contribution is making that story \emph{post-quantum} via the Pulse, not classical-only via a BLS aggregate or oracle attestation.

\subsection{Chainlink CCIP}

CCIP \cite{ccip} couples a Chainlink-operated oracle network with a separate Risk Management Network (RMN) for cross-chain message attestation. The cross-chain envelope is signed by the oracle network; the RMN provides a separately signed risk-management attestation.

\paragraph{Source-finality basis.} Oracle attestation. The destination chain trusts that the oracle network correctly observed the source chain's finality and signed accordingly. The trust model is the union of the oracle network's classical signature scheme and the RMN's classical signature scheme.

\paragraph{Differences vs Warp 2.0.} (1) CCIP's source finality is oracle-attested; Warp 2.0's is source-validator-signed (the source's own validator set produces the Pulse). (2) CCIP is classical-only; Warp 2.0 is hybrid PQ via the Pulse. (3) CCIP composes two oracle networks (Chainlink + RMN); Warp 2.0 composes three signing lanes (Beam + ML-DSA + Pulse) on the same source-validator set.

\paragraph{Where they could meet.} A CCIP-style oracle-attested envelope could carry a Pulsar Pulse attesting the oracle's view; the destination would verify the oracle's PQ-signed view rather than its classical-signed view. The integration is straightforward; the open work is on the CCIP side, not Warp 2.0's.

\subsection{Wormhole}

Wormhole \cite{wormhole} uses a 19-validator ``guardian'' network that signs cross-chain Verified Action Approvals (VAAs). The destination chain verifies the guardian quorum signature against the Wormhole guardian-key registry.

\paragraph{Source-finality basis.} Guardian-network attestation. The destination trusts that the guardians correctly observed the source's finality and signed.

\paragraph{Differences vs Warp 2.0.} (1) Wormhole's source finality is guardian-attested (a separate $19$-of-$13$ committee); Warp 2.0's is source-validator-signed (the source chain's own validator set produces the Pulse, no separate committee). (2) Wormhole is classical-only (Ed25519 guardian keys); Warp 2.0 is hybrid PQ. (3) Wormhole's guardian set is fixed-size and externally curated; Warp 2.0's source-validator set is whatever the source chain runs, with LSS-managed dynamic resharing.

\paragraph{Wormhole 2.x and PQ.} Wormhole has signaled intent to add PQ signatures to the guardian quorum. The shape would be analogous to Warp 1.x $\to$ 2.0 evolution. The structural difference remains: Wormhole's source finality routes through a separate guardian set; Warp 2.0's routes through the source's own validators.

\subsection{IBC}

IBC \cite{ibc} (Inter-Blockchain Communication) uses light clients on the destination chain that follow the source chain's consensus headers. Source finality is verified by the destination running a verifier of the source's consensus protocol.

\paragraph{Source-finality basis.} Direct consensus verification. The destination's IBC light client tracks the source's consensus state (Tendermint's prevote / precommit aggregate) and accepts cross-chain envelopes that the source has finalized.

\paragraph{Differences vs Warp 2.0.} (1) IBC requires the destination to run a full source-consensus verifier; Warp 2.0 requires only a $\mathsf{GroupKeyResolver}$ keyed by source $(\eta, g)$. (2) IBC is classical-only (Tendermint Ed25519); Warp 2.0 is hybrid PQ. (3) IBC's verification cost on the destination scales with the source's validator set size and per-block signature verification; Warp 2.0's verification cost is constant in the source's validator set size (one Pulse verify, one BLS aggregate verify, one ML-DSA cert-set verify or one Groth16 verify).

\paragraph{The light-client tradeoff.} IBC's tightest binding to source finality is a strength: the destination can verify any source-finality property without trusting an oracle. The cost is operational: every source chain requires a separate IBC light client implementation on every destination. Warp 2.0 trades the tightest binding for a uniform $\mathsf{GroupKeyResolver}$ interface; the destination only needs to know the source's GroupKey lineage, not its full consensus rules.

\subsection{LayerZero}

LayerZero \cite{layerzero} couples an oracle (delivering source block headers) with a relayer (delivering cross-chain message proofs against those headers). The destination chain accepts a message iff the oracle and relayer agree.

\paragraph{Source-finality basis.} Oracle + relayer agreement. The destination trusts that the oracle correctly observed the source's finality and that the relayer's proof is valid against the oracle's header.

\paragraph{Differences vs Warp 2.0.} (1) LayerZero's source finality routes through two separate trusted parties; Warp 2.0's routes through the source's own validator set. (2) LayerZero is classical-only; Warp 2.0 is hybrid PQ. (3) LayerZero's trust model is two-of-two oracle / relayer; Warp 2.0's is the source's own $\geq 2/3$-weight validator quorum.

\subsection{Comparison table}

\begin{tabular}{@{}p{0.13\textwidth}p{0.30\textwidth}p{0.10\textwidth}p{0.36\textwidth}@{}}
  \toprule
  \textbf{Protocol} & \textbf{Source-finality basis} & \textbf{PQ?} & \textbf{Trust model} \\
  \midrule
  CCIP & Oracle network + RMN & no & Oracle network classical sigs $\cup$ RMN classical sigs \\
  Wormhole & 19-validator guardian network & no & Guardian quorum classical sigs \\
  IBC & Direct source-consensus verifier (light client) & no & Source's classical consensus correctness \\
  LayerZero & Oracle (block header) + relayer (message proof) & no & Oracle classical sigs $\cap$ relayer correctness \\
  \textbf{Warp 1.x} & \textbf{Source validator BLS aggregate} & \textbf{no} & \textbf{Source's $\geq 2/3$-weight BLS} \\
  \textbf{Warp 2.0} & \textbf{Source validator Pulse + Beam + ML-DSA cert set} & \textbf{yes (hybrid)} & \textbf{Source's $\geq 2/3$-weight Pulse + Beam + ML-DSA, conjunctive Prism predicate} \\
  \bottomrule
\end{tabular}

The Warp 2.0 row is the only design that makes source-finality post-quantum and routes through the source's own validators. The combination is the contribution.

\subsection{Where Warp 2.0 sits in the cross-chain design space}

Warp 2.0's design space coordinates:
\begin{itemize}[leftmargin=2em,nosep]
  \item \textbf{Trust routing}: source validators (Warp 1.x / 2.0) vs separate committee (Wormhole) vs oracle network (CCIP, LayerZero) vs direct light-client verification (IBC).
  \item \textbf{Cryptographic basis}: classical aggregate (BLS, Ed25519) vs hybrid PQ (Pulse + Beam + ML-DSA).
  \item \textbf{Source-finality binding}: NebulaRoot + KeyEra/Generation lineage (Warp 2.0) vs block header (IBC) vs payload-only (Warp 1.x, CCIP, Wormhole, LayerZero).
\end{itemize}

Warp 2.0's coordinates are: source validators, hybrid PQ, NebulaRoot + lineage. The space is not exhaustively covered; the four neighbors illustrate the trade-offs but do not bound the design space. A future protocol could combine, e.g., a source-validator routing with a STARK proof of finality (no $\mathsf{GroupKeyResolver}$ needed); the open work is the production deployment of such systems, and the conditions under which they outperform Warp 2.0.

\subsection{Status}

Warp 2.0 ships in the Mar-3 freeze. Warp 1.x remains available only on its own independent legacy channel. The wire is forward-only; the two channels coexist without negotiation. Cross-chain destinations on Lux mainnet (Lux $\to$ Hanzo, Lux $\to$ Zoo, etc.) verify v2 envelopes against the source chain's Pulsar GroupKey lineage as recorded in their on-chain source-key-registry contracts. The PaaS deployment path \cite{lp105} updates the registry contracts as the source chains' Reanchor lifecycles dictate; no out-of-band oracle is required.