papers/lp-218-zap-p3q-pq-rollup/sections/01-introduction.tex

\section{Introduction}

This paper expands on LP-218
(\texttt{lps/LP-218-zap-p3q-pq-rollup.md}) with the six-step pattern
as a numbered list (alongside the user's five-step framing), the
four wire envelopes, the P3Q precompile interface and honest gas
accounting, the two rollup modes (optimistic vs ZK), and the
inherited cert mode contract that ties rollup finality to the
parent L1's LP-217 mode.

\subsection{Setup: what a rollup is here}

A ZAP-native PQ rollup is a Tier-3 chain (per LP-204) whose
sequencer collects $N$ transactions as ZAP frames, applies them
against the rollup state, computes a new state root over the
ZAP-buffer Merkle structure defined in LP-203, and signs the tuple
$(\textrm{prev\_root}, \textrm{new\_root}, \textrm{batch\_hash},
\textrm{sequencer\_id})$ with a Pulsar threshold signature (LP-073).
The sequencer submits
\texttt{RollupBatchTx\{prev\_root, new\_root, batch\_hash, pulsar\_sig\}}
as a ZAP frame to Z-Chain (the parent L1 Tier-1 hosting the
rollup-VM at Tier-3 in the LP-204 hierarchy).

\subsection{What was wrong before}

Traditional optimistic rollups (Arbitrum, Optimism) require a
rollup-side validator set or sequencer + fraud-proof window of
$\geq 7$ days, plus a bridge contract on the parent L1 that maintains
its own state. Three concrete failures:

\begin{enumerate}[leftmargin=2em,nosep]
\item \textbf{Cryptographic authenticity is implicit.} The sequencer
  is a single entity (or unaudited multisig) with no cryptographic
  attestation that survives parent-L1 verification. The bridge
  trusts the sequencer's signature on a classical secp256k1 key.
\item \textbf{Finality window is operational, not cryptographic.}
  The 7-day challenge window is a function of operator policy, not
  a cryptographic property. Reducing it requires a fraud-proof
  game executed by validators who must observe and challenge within
  the window.
\item \textbf{PQ posture is absent.} The bridge contract verifies
  secp256k1 ECDSA, broken by Shor's algorithm. A
  store-now-decrypt-later adversary can wait until quantum hardware
  is available to forge sequencer batches retroactively.
\end{enumerate}

\subsection{What this LP solves}

LP-218 ties rollup finality to the parent L1's QuasarCert. Z-Chain
validators verify the Pulsar signature via the \textbf{P3Q
precompile at EVM slot \texttt{0x012205}}. P3Q is the on-chain
verifier defined in HANZO-CRYPTO-SUITE §5.2 -- a single precompile
that takes a Pulsar threshold signature, a message hash, and a
group public key, and returns true iff the signature validates.
The verification is part of normal Z-Chain block validation; no
second consensus is needed. The Z-Chain block then finalizes via
the parent L1's QuasarCert (LP-202 tier degradation: PQ-off $\to$
PQ-fast $\to$ PQ-strict $\to$ PQ-heavy per LP-217).

The rollup state inherits the parent L1's full cryptographic
finality because the rollup commit IS a Z-Chain transaction and
Z-Chain IS the parent L1's rollup substrate (LP-063 + LP-204). No
rollup-side validator set exists. No fraud-proof bond is required
for the cryptographic path -- the Pulsar signature is sufficient
for the authenticity of the state transition; an optimistic-rollup
challenge window is only needed if a fraud-proof system is the
integrity model of the execution itself.