papers/lux-lightspeed-dex/sections/08-settlement-blockstm.tex

\section{Parallel Settlement}
\label{sec:settlement}

Matching produces fills; settlement applies them to balances. At the matching rates of
Section~\ref{sec:gpu-matching}, serial settlement would be the new bottleneck. We settle in
parallel with market-sharded Block-STM---optimistic parallel execution with deterministic
conflict resolution---reusing the engine already present in the Lux EVM rather than building
a new one.

\subsection{Why parallel settlement is tractable here}

A fill touches two accounts (maker and taker) within one market. Across a venue running
thousands of markets, the great majority of fills in a block touch disjoint account sets, so
conflicts are rare. Sharding the settlement batch by market makes each fill intra-shard by
construction; only a small residue of cross-shard fills must be reconciled. This is the
ideal shape for optimistic parallel execution: speculate on all fills in parallel, detect
the few real conflicts, and merge deterministically.

\subsection{Block-STM with market sharding}

We reuse the Aptos-style Block-STM executor in the Lux EVM, sharing its conflict-detection
kernel with the DEX settlement path rather than duplicating it. The conflict kernel builds
read/write-set edges and produces a deterministic commit order; the same kernel exists on
CPU and on GPU (CUDA/HIP/Metal/WGSL/Vulkan).

\begin{table}[H]
\centering
\renewcommand{\arraystretch}{1.25}
\begin{tabular}{l l r}
\toprule
\textbf{Stage} & \textbf{Backend} & \textbf{Rate} \\
\midrule
Conflict detection ($O(N)$ hash-map) & CPU & 2.2\,M fills/s ($\sim$0.27\,$\mu$s/fill) \\
Conflict detection (KAT-verified)    & GPU (WGSL on M4) & byte-identical commit order \\
Batch settle (no per-fill copy)      & CPU & $\sim$0.19\,M fills/s \\
Market-sharded settle (8 shards)     & CPU & $\sim$0.39\,M fills/s ($\sim$2.05$\times$) \\
\bottomrule
\end{tabular}
\caption{Measured settlement stages (CPU on Apple M1 Max). Conflict detection is cheap and
flat in the conflict rate; the GPU conflict kernel produces a commit order byte-identical to
the CPU oracle on real silicon, so the parallel layer is consensus-safe. Market sharding
gives near-linear scaling of the apply stage.}
\label{tab:settlement}
\end{table}

The conflict-detection \emph{layer} scales cleanly: the $O(N)$ kernel runs at 2.2\,M fills/s
flat across conflict rates, and the GPU kernel was verified to produce the same commit order
as the CPU oracle (7/7 KAT pass on a real M4 GPU). That byte-identical commit order is what
makes GPU-assisted settlement safe to put under consensus---the parallel result equals the
serial result.

\subsection{The honest bottleneck: state apply, not conflict detection}

The Block-STM executor is structurally correct, but on a general EVM \texttt{StateDB} it
delivers \emph{no} parallel speedup---it was measured slower than serial---because the naive
speculation path deep-copies the entire state per item. This is the same failure class as
copying a whole order book to the GPU on every call: the copy, not the computation, is the
cost. We state this plainly: the conflict layer is fast (2.2\,M fills/s), but a copy-per-fill
apply collapses to hundreds of fills per second.

The fix is not a different conflict engine; it is (i) market sharding, so each fill is
intra-shard and no copy of unrelated state is needed, and (ii) applying against the D-Chain's
\texttt{zapdb}/versioned overlay, which is far lighter than a general EVM \texttt{StateDB}.
The overlay is the D-Chain's native settlement path, so settlement composes with matching on
the same chain rather than crossing into a heavyweight state model. The cross-shard residue
(a few percent of fills) is merged once per block at block cadence, not per order, so the
merge is not the bottleneck---the per-shard apply is, and the overlay is the lever that
lightens it.

\subsection{Composition}

Settlement is one of three independently measured axes. Matching runs per-book in parallel
(Section~\ref{sec:gpu-matching}); settlement runs market-sharded in parallel against the
overlay (this section); finality runs through the rollup (Section~\ref{sec:rollup}). The
seam between matching and settlement is a fill batch keyed by market, which is exactly the
shard key, so the two stages line up without a reshaping step.