mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-03 05:07:46 +00:00
zeekayandHanzo Dev
178febad68
Every rendered "T-Chain" / "ThresholdVM" / "teleportvm" reference across the paper corpus is rewritten to the correct canonical chain by concern: threshold signing / MPC / bridge custody / key recovery -> M-Chain (MVM); FHE / encrypted compute / threshold decryption -> F-Chain (FVM); teleport / cross-chain messaging -> B-Chain (bridgevm); consensus Pulsar stays Q-Chain. Section lux-trust-kernel/03-t-chain-threshold-governance.tex renamed -> 03-f-chain-encrypted-policy.tex (with \input + xref fixes). Braided "T-Chain" sections split by concern (M vs F). Only lp-020's chain-separation rationale and the shared lux/chains/thresholdvm library path retain the name, to record the removal. All changed papers rebuilt (pdflatex, rc=0, no undefined refs). ยง09 of lux-dao-governance-framework reframed: fabricated "production deployment" metrics ($50M/$240k/$12M, survey %s, "as of Oct 2024") relabeled as illustrative design configurations with no invented replacements; reality noted (DAO treasury is a 1/1 Safe); conclusion echo + one "first production" overclaim softened. This commit also captures concurrent corpus workstreams on the same tree. Co-authored-by: Hanzo Dev <[email protected]>
68 lines
3.2 KiB
TeX
68 lines
3.2 KiB
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 by the P3Q framework (LP-219) -- 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.
|