mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +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]>
97 lines
4.3 KiB
TeX
97 lines
4.3 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.} An early LP-218 Draft
|
|
targeted the Plonky3-fork STARK at \texttt{0x012205}; the canonical
|
|
allocation is \texttt{0x012205} = the P3Q signature-dispatch wrapper
|
|
(LP-219), sharing the slot with its raw-primitive owner by kind byte,
|
|
while the STARK relocated to its own slot \texttt{0x012220} (starkfri,
|
|
LP-221). 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}.
|