mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-02 11:39:52 +00:00
zeekay
d43bd27971
Companion LaTeX papers to luxfi/LPs: - lp-200-zap-stack: full ZAP-as-substrate paper (10-layer model, deco- mplected concerns, performance). - lp-200-lux-vs-avalanche-diff: code-translation appendix. - lp-203-gpu-native-verify, lp-205-pipelined-quasar, lp-208-dag-mempool, lp-209-mysticeti-ordering, lp-210-block-stm, lp-211-cross-shard-atomic, lp-217-cert-profile-modes, lp-218-zap-p3q-pq-rollup, lp-220-p3q-corona-magnetar, lp-221-stark-fri-verifier, lp-300-schema-registry. Pitch / outreach decks (luxcover.sty templated): - blackrock-nahmii-pitch, corporate-dao-stack-analysis, nahmii-patent-acquisition, pq-patent-family-future-infringers, lux-substrate-platform-pitch, w3a-foundation-membership, multi-validator-scale, vfs-archive-cost-study. Edits aligning to LP-217 / LP-200: - lp-020-quasar-consensus 02-system-model + 08-performance. - lp-073-pulsar 11-quasar. - lp-103-omnichain-explorer 03-chain-support. - lp-104-graph-engine. - lp-201-zap-universal-wire/wire-inventory.csv. - lp-306-lx-social-dex sections/02. - lux-adoption-roadmap, lux-chain-architecture, lux-consensus-engines/08-composition, lux-crypto-agility, lux-evm-precompile-engineering/02, lux-fhe-smart-contracts/05, lux-quasar-composition/04+06+10, lux-reproducible-builds. - INDEX.md cross-links the new papers.
95 lines
4.2 KiB
TeX
95 lines
4.2 KiB
TeX
\section{Introduction}
|
|
|
|
LP-300 is a meta-registry. It allocates no new wire bytes, no new
|
|
precompile slots, no new schemas. Its sole job is to record -- in
|
|
one normative place -- every allocation made by every other LP in
|
|
the corpus. Where a consuming LP says ``this draft uses TypeKind
|
|
\texttt{0xE8}'', LP-300 says ``\texttt{0xE8} is owned by LP-218;
|
|
here is the row.''
|
|
|
|
\subsection{Why a master registry}
|
|
|
|
Three years of LP authoring have accumulated 25 LPs that touch one
|
|
of three address spaces -- the ZAP TypeKind byte, the per-TypeKind
|
|
ShapeKind byte, or an EVM precompile slot. The allocations live in
|
|
the ``Wire schemas'' section, the ``Precompile slot'' section, the
|
|
``Schema-ID allocation map'', or scattered tables in the LP body.
|
|
Three concrete failure modes follow:
|
|
|
|
\begin{enumerate}[leftmargin=2em,nosep]
|
|
\item \textbf{Allocation drift.} LP-208 originally allocated
|
|
\texttt{0xF0..0xFF} for DAG mempool. LP-214 then allocated
|
|
\texttt{0xF0..0xF2} for light client. The conflict went undetected
|
|
until LP-218 also targeted the same range. LP-208 quietly
|
|
re-homed to \texttt{0xE0..0xE1} -- but the original Draft text in
|
|
several places still cites \texttt{0xF0}.
|
|
\item \textbf{Slot triple-claim.} LP-208 (\texttt{0xE0..0xE1}),
|
|
LP-211 (\texttt{0xE2..0xE7}), and an earlier LP-218 Draft
|
|
(\texttt{0xE0..0xEF}) all claimed bytes inside \texttt{0xE0..0xEF}.
|
|
Three Drafts cannot all be Final without arbitration.
|
|
\item \textbf{Wrapper-over-primitive ambiguity.} LP-0120 owns the
|
|
PQ precompile slot \texttt{0x012205} as Plonky3-fork STARK.
|
|
LP-218 attaches a P3Q wrapper on the same slot. Two LPs nominally
|
|
``own'' the same hex digit. The wrapper-vs-primitive distinction
|
|
is real but invisible without a registry that records both.
|
|
\end{enumerate}
|
|
|
|
The fix is decomplecting: separate \emph{authoritative allocation}
|
|
(LP-300) from \emph{wire behavior specification} (the consuming LP).
|
|
A consuming LP becomes informative-only on the allocation question.
|
|
LP-300 wins any disagreement.
|
|
|
|
\subsection{Three orthogonal namespaces}
|
|
|
|
LP-300 partitions every allocation into three orthogonal namespaces
|
|
plus one out-of-scope namespace. Cross-namespace collisions are
|
|
impossible by construction because each lives in a different address
|
|
space:
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\small
|
|
\begin{tabular}{@{}lp{3.6cm}p{2.8cm}p{4.4cm}@{}}
|
|
\toprule
|
|
\textbf{\#} & \textbf{Namespace} & \textbf{Width} & \textbf{Carrier} \\
|
|
\midrule
|
|
1 & TypeKind byte & 1 byte (\texttt{0x00--0xFF}) & byte 0 of every ZAP envelope on the wire \\
|
|
2 & ShapeKind byte & 1 byte, namespaced under each TypeKind & byte 1 of every ZAP envelope (per TypeKind table) \\
|
|
3 & Precompile slot & uint16 / uint24 / uint160 & EVM precompile address \\
|
|
4 & Genesis assetID / chainID (out of scope) & uint32 / uint160 & per-chain genesis blob \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\caption{The four allocation namespaces. LP-300 is normative for
|
|
namespaces 1, 2, and 3; namespace 4 is owned by LP-019 / LP-099 /
|
|
LP-134 and is referenced here only to disclaim overlap. The terms
|
|
``schema ID'' and ``TypeKind byte'' are used interchangeably
|
|
throughout the LP corpus; they name the same byte.}
|
|
\label{tab:namespaces}
|
|
\end{table}
|
|
|
|
\subsection{What this paper is not}
|
|
|
|
LP-300 is a reference document. It contains no measured benches:
|
|
the registry ships no wire change, so there is nothing to measure.
|
|
It contains no engineering tradeoffs: the tradeoffs were made by
|
|
the consuming LPs and are documented there. It contains no
|
|
operator-facing config: nothing in LP-300 is configurable at
|
|
runtime.
|
|
|
|
What LP-300 \emph{does} contain: every byte allocated, every slot
|
|
allocated, the owner LP for each row, the conflict resolution
|
|
log for the four pre-existing conflicts, the cooldown policy for
|
|
deprecated allocations, and the cross-referencing pattern every
|
|
consuming LP MUST follow.
|
|
|
|
\subsection{Final from genesis}
|
|
|
|
LP-300 activates at the genesis of the new final Lux network --
|
|
unix \texttt{1766708400} = 2025-12-25T16:20:00-08:00 -- with no
|
|
migration window. A meta-registry that ships no wire change has
|
|
nothing to migrate; it is Final the moment the network is. Any
|
|
post-activation amendment is an additive new row, never a
|
|
re-allocation of a live slot. Re-allocation of a deprecated slot
|
|
requires the one-year cooldown documented in
|
|
\S\ref{sec:cooldown}.
|