mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
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.
65 lines
3.2 KiB
TeX
65 lines
3.2 KiB
TeX
\section{Introduction}
|
|
|
|
This paper expands on LP-200 (\texttt{lps/LP-200-zap-stack.md}) with
|
|
detail on the ten-layer model, the decomplected concerns, the measured
|
|
per-operation cost wins, and the explicit composition table tying the
|
|
umbrella to its sibling LPs.
|
|
|
|
The Lux ZAP Stack is the architectural commitment of the new final Lux
|
|
network. It is activated at unix timestamp \texttt{1766708400}
|
|
(2025-12-25 16:20 Pacific) -- the genesis of the new network. There is
|
|
no migration path because there is nothing to migrate: the pre-Quasar
|
|
Edition Lux network (2020--2025) is a separate network operating a
|
|
different stack, and is out of scope.
|
|
|
|
\subsection{What was wrong before}
|
|
|
|
The legacy blockchain stack that the new network replaces -- a
|
|
direct descendant of the Avalanche-derived codebase Lux forked from in
|
|
2019 -- braided wire, in-memory, and on-disk concerns through a
|
|
runtime \texttt{codec.Manager} registry. Every transaction was
|
|
unmarshalled into a Go struct on receive, re-marshalled into a
|
|
storage row on insert, unmarshalled again from storage on read,
|
|
re-marshalled into the gossip envelope on broadcast, and re-marshalled
|
|
yet again into the snapshot stream on backup. Five encode/decode
|
|
hops per transaction, each paying a reflection cost, each requiring a
|
|
runtime codec-version registry lookup, each allocating fresh Go
|
|
structs that the garbage collector eventually had to reclaim. The
|
|
braiding was load-bearing: removing one hop required touching the
|
|
other four.
|
|
|
|
\subsection{What this LP solves}
|
|
|
|
The ZAP Stack unbraids the wire from the in-memory representation
|
|
from the on-disk record. A transaction is a binary buffer when it
|
|
crosses the wire (LP-022); it is the same buffer in the mempool; it
|
|
is the same buffer when a block frame references it by offset; it is
|
|
the same buffer when ZapDB streams it to an age-encrypted snapshot.
|
|
One byte stream, ten orthogonal layers reading and producing bytes,
|
|
no codec registry.
|
|
|
|
The reason this matters is operational, not aesthetic. The cost of
|
|
every braided hop in the legacy stack is paid \emph{every block}.
|
|
Removing the braids removes the cost. The architectural commitment is
|
|
the load-bearing one; the measured wins (Section~\ref{sec:performance})
|
|
confirm it but are not the point. The point is that each of the ten
|
|
layers is independently complete and orthogonal to its siblings, so
|
|
that future work (rollups, light clients, state commitments) composes
|
|
without re-litigating the encode/decode boundary.
|
|
|
|
\subsection{Values, not places}
|
|
|
|
Rich Hickey distinguishes places (slots that hold different things
|
|
over time) from values (things that do not change). ZAP-native is
|
|
values all the way down: the buffer that arrives over the wire is the
|
|
same buffer in the mempool, the same buffer in the block, the same
|
|
buffer in state, the same buffer in the snapshot. The identity is a
|
|
function of the buffer; the transcript is a function of the buffer;
|
|
the signature is over a window of the buffer. Nothing mutates.
|
|
Nothing re-encodes. The buffer is the value.
|
|
|
|
This is the same discipline applied throughout: profile gating is one
|
|
function in one place (LP-217); the wallet builder's fee-asset is one
|
|
field with one canonical name (\texttt{UTXOAssetID}); the cert is one
|
|
struct shape across all modes (LP-182). One way to do each thing.
|