mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekayandHanzo Dev
e2cb62c540
I resolved these files toward a June commit that called the billion-order figures fabricated, and that commit was itself the mistaken one. The July campaign it predates does not assert its numbers, it checks them: a GPU-versus-CPU parity run matching exactly, 38,000,000 fills on both sides at 1,000,000 books, depth 32, 32 takers each, on hardware this estate owns. It also names the error in the earlier framing. Consensus determinism was taken to force a single-thread launch and forfeit the GPU. It does not: determinism constrains ordering WITHIN a book and says nothing across books, so one thread per book — each matching its taker stream in strict price-time priority, bit-for-bit re-executable, millions of threads — saturates the accelerator with every book deterministic. Restored at the later versions across all 27 files: the accounting section, the CLOB matcher, lightspeed-dex, lp-306, lp-308, lp-137, p3q-corona, the precompile engineering sections and the FHE orderbook application. Paper builds, 23 pages, no errors. Co-authored-by: Hanzo Dev <[email protected]>
77 lines
4.4 KiB
TeX
77 lines
4.4 KiB
TeX
\section{Introduction}
|
|
|
|
Decentralized exchanges (DEXs) trade away performance for trustlessness. The
|
|
constant-product automated market maker (AMM) that dominates on-chain trading
|
|
prices every swap against a bonding curve, settles at block cadence, and exposes
|
|
order flow to reordering. The result is high slippage, slow finality, and value
|
|
extracted from users by adversarial transaction ordering~\cite{daian2020}.
|
|
High-frequency trading---resting limit orders, price-time priority, marketable
|
|
order execution in microseconds---has no native home on a public chain.
|
|
|
|
The obstacle is structural, not merely a matter of faster hardware. A general-purpose
|
|
EVM chain matches orders \emph{inside} a smart contract: every cross walks storage,
|
|
pays opcode-dispatch overhead, and is re-executed by every validator. Throughput is
|
|
bounded by the slowest validator's serial EVM, and latency is bounded by block time.
|
|
Bolting a faster matching engine onto such a chain does not help if the engine still
|
|
runs once per validator under the EVM's execution model.
|
|
|
|
\subsection{Approach: the DEX is a chain}
|
|
|
|
We do not add a DEX to a chain. \textbf{The DEX is a chain}---the \textbf{D-Chain},
|
|
a single-operator consensus chain whose sole purpose is matching and settling orders.
|
|
It has its own consensus, its own \texttt{zapdb} persistence, and an execution-root
|
|
state commitment in the style of the Lux XVM. It is the one and only place where
|
|
orders match and where DEX state lives. Matching runs against a native C++/GPU engine
|
|
behind a deterministic Go reference; the GPU path is gated to be byte-identical to the
|
|
reference (Section~\ref{sec:gpu-matching}).
|
|
|
|
Everything else is kept orthogonal:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{Atomic proxy} (\texttt{chains/dexvm}): a \emph{stateless} component
|
|
on the public Lux network. It relays orders to the D-Chain over ZAP and moves
|
|
value in and out atomically via shared-memory import/export---the same mechanism
|
|
the X-Chain and C-Chain use to exchange assets. It holds no order book and no DEX
|
|
state (Section~\ref{sec:architecture}).
|
|
\item \textbf{Client wrapper} (\texttt{luxfi/dex}): a Go client SDK and ZAP
|
|
gateway. It carries no matching logic of its own.
|
|
\item \textbf{EVM CLOB facade} (precompile \texttt{0x9999}): a Uniswap-V4-style
|
|
\texttt{PoolManager} surface that is a \emph{central limit order book}, not an AMM.
|
|
It is an EVM/Solidity adapter into the unified D-Chain and is inert unless a venue
|
|
configures a D-Chain endpoint (Section~\ref{sec:precompile}).
|
|
\end{itemize}
|
|
|
|
The public open-source \texttt{luxd} validates the P-, C-, and X-Chains and other
|
|
sovereign L1s and \emph{excludes} the D-Chain, which is gated behind a build tag and
|
|
carries zero private dependencies. A private venue build links the C++/GPU engine.
|
|
This is the public/private seam: the open network never depends on the proprietary
|
|
matcher, and the proprietary matcher never leaks into the open network.
|
|
|
|
\subsection{Contributions}
|
|
|
|
\begin{enumerate}
|
|
\item A \textbf{decomplected} DEX architecture with one home per concern: matching
|
|
and state on the D-Chain, atomic value transport in the proxy, the client in the
|
|
wrapper, and an inert-by-default EVM facade (Sections~\ref{sec:architecture},
|
|
\ref{sec:precompile}).
|
|
\item A \textbf{consensus-determinism} discipline that runs the matcher in
|
|
\texttt{Block.Verify} against a versioned overlay and carries fills in the block
|
|
bytes, eliminating wall-clock and randomness from the consensus path
|
|
(Section~\ref{sec:determinism}).
|
|
\item A \textbf{measured}, byte-parity-gated GPU CLOB matcher: 9.13\,B orders/sec on
|
|
an NVIDIA GB10, 12.76\,B on an AMD Radeon 8060S, and 5.60/2.80\,B on Apple M4 Max/M1 Max,
|
|
byte-identical to a CPU oracle---billions of orders/sec on a single device, scaling
|
|
linearly across a fleet (Section~\ref{sec:gpu-matching}).
|
|
\item A \textbf{market-sharded Block-STM} settlement path with a measured
|
|
conflict-detection rate, byte-identical CPU and GPU commit order
|
|
(Section~\ref{sec:settlement}).
|
|
\item A \textbf{rollup to the Z-Chain} that verifies one proof per $K$ trades, with
|
|
measured P3Q (ML-DSA) and \texttt{starkfri} (STARK/FRI) verification rates and an
|
|
honest separation of settlement \emph{finality} from matching throughput
|
|
(Section~\ref{sec:rollup}).
|
|
\end{enumerate}
|
|
|
|
All performance figures in this paper are measured on stated hardware and gated by
|
|
byte-exact parity against a reference oracle. Where a number is a projection, we label
|
|
it as such.
|