mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
663cc83ca3
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.
77 lines
3.2 KiB
TeX
77 lines
3.2 KiB
TeX
\section{Conflict resolution policy}
|
|
\label{sec:policy}
|
|
|
|
LP-300 is the single source of truth. Any future schema ID, TypeKind
|
|
byte, ShapeKind byte, or EVM precompile slot allocation MUST be added
|
|
here first; the consuming LP MUST reference (not duplicate) the
|
|
assignment.
|
|
|
|
\subsection{Adding a new allocation}
|
|
|
|
\begin{enumerate}[leftmargin=2em,nosep]
|
|
\item The proposer opens a PR against LP-300 listing the requested
|
|
slot(s), the consuming LP number, and a one-line purpose. The PR
|
|
cites the namespace (TypeKind / ShapeKind / Precompile) and the
|
|
authoritative section in this paper that the new row will join.
|
|
\item The PR is merged BEFORE the consuming LP can be promoted past
|
|
``Draft'' status. A consuming LP at ``Final'' without a matching
|
|
LP-300 row is itself in violation.
|
|
\item The consuming LP's ``Wire schemas'' or ``Precompile slot''
|
|
section references LP-300 by row; it does not re-state the
|
|
allocation. The consuming LP becomes informative-only on the
|
|
allocation question.
|
|
\end{enumerate}
|
|
|
|
\subsection{Resolving overlap}
|
|
|
|
If two LPs claim overlapping ranges:
|
|
|
|
\begin{enumerate}[leftmargin=2em,nosep]
|
|
\item The LP-300 maintainer arbitrates. The default rule: the
|
|
chronologically earlier ``Final'' claim wins; the later claim
|
|
relocates to the next free range. Pre-activation, neither has
|
|
shipped wire bytes -- the call is editorial.
|
|
\item The losing LP is amended to point at its new range, and an
|
|
``Activation marker'' note is added to LP-300 stating ``Was
|
|
\texttt{<old range>}; moved to \texttt{<new range>} per LP-300
|
|
\S\ref{sec:conflicts}.''
|
|
\item Pre-activation (before unix \texttt{1766708400}), reshuffles
|
|
are free because no production wire bytes have shipped.
|
|
Post-activation, reshuffles require a network upgrade.
|
|
\end{enumerate}
|
|
|
|
\subsection{Maintainer authority}
|
|
|
|
The LP-300 maintainer is the editor of last resort for any allocation
|
|
conflict. The maintainer's role is to record decisions in this paper;
|
|
the decisions themselves come from the technical leads of the
|
|
consuming LPs. When the consuming LPs cannot agree, the maintainer
|
|
applies the ``earliest Final wins'' rule from above.
|
|
|
|
The four conflicts already resolved (\S\ref{sec:conflicts}) were
|
|
arbitrated by the LP-300 maintainer in 2026-05 -- 2026-06. All four
|
|
resolutions are now Final.
|
|
|
|
\subsection{Wire bytes and the activation cliff}
|
|
|
|
Pre-activation (before \texttt{1766708400}), LP-300 is a planning
|
|
document and reshuffles cost nothing. The four conflicts in
|
|
\S\ref{sec:conflicts} were all resolved pre-activation; no shipped
|
|
wire byte changed semantics.
|
|
|
|
Post-activation, every byte allocated in LP-300 is interpreted by
|
|
some live validator somewhere. A reshuffle past this point is a
|
|
network upgrade, with all the operational cost that implies:
|
|
coordinated node rollout, dual-decode windows for the old and new
|
|
allocations, and an explicit deprecation cooldown
|
|
(\S\ref{sec:cooldown}) on the old slot. Post-activation reshuffles
|
|
should be rare.
|
|
|
|
\subsection{Out-of-band edits forbidden}
|
|
|
|
A consuming LP MUST NOT silently change an allocation it owns. The
|
|
canonical procedure is: open the LP-300 amendment PR first, get it
|
|
merged, then propagate the change to the consuming LP. Even a
|
|
typographic correction to an allocation row goes through the LP-300
|
|
amendment process to preserve the audit trail.
|