Files
papers/lux-fhe-mpc-hybrid/sections/06-application-private-orderbook-matching.tex
zeekayandHanzo Dev e2cb62c540 Restore the measured DEX campaign the merge had reverted
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]>
2026-09-01 08:16:10 -07:00

83 lines
4.1 KiB
TeX

\section{Application: Private Orderbook Matching}
We instantiate the FHE+MPC hybrid for a private orderbook matching engine deployed on the Lux network.
\subsection{Problem Statement}
$N$ market participants submit limit orders (buy/sell, price, quantity, asset pair). The matching engine must:
\begin{enumerate}[leftmargin=2em]
\item Match overlapping buy/sell orders at the intersection price.
\item Reveal only matched trades to the relevant counterparties.
\item Never reveal the full order book to any single party---including the matching engine itself.
\end{enumerate}
\subsection{Protocol}
\begin{enumerate}[leftmargin=2em]
\item \textbf{Order submission.} Each participant encrypts their order $(side, price, quantity)$ under the FHE public key and submits the ciphertext on-chain.
\item \textbf{Homomorphic matching.} The matching engine (a smart contract or off-chain coprocessor) evaluates the matching logic on encrypted data:
\begin{itemize}
\item Compare encrypted prices: $\text{FHE.Compare}(\text{bid}_i, \text{ask}_j) \to \text{ct}_{match}$
\item Compute matched quantity: $\text{FHE.Min}(\text{qty}_i, \text{qty}_j) \to \text{ct}_{fill}$
\item Generate encrypted trade receipts for matched pairs.
\end{itemize}
\item \textbf{Selective decryption.} Only matched trade receipts are submitted to the MPC committee for threshold decryption. Unmatched orders remain encrypted and are never decrypted.
\item \textbf{Settlement.} Decrypted trade receipts are executed on-chain. The MPC attestation proves correct decryption.
\end{enumerate}
\subsection{Security Properties}
\begin{center}
\begin{tabular}{ll}
\toprule
\textbf{Property} & \textbf{Guarantee} \\
\midrule
Order privacy & Unmatched orders are never decrypted by anyone \\
Matching integrity & FHE evaluation is deterministic and verifiable \\
No front-running & Matching engine cannot read encrypted prices \\
Selective disclosure & Only counterparties learn trade details \\
Threshold trust & $t$-of-$n$ MPC nodes must collude to break privacy \\
\bottomrule
\end{tabular}
\end{center}
\subsection{Throughput: The Bootstrap Is the Bottleneck}
Privacy is not free, and the price is throughput. Every comparison and
minimum in the homomorphic matching step is a sequence of boolean gates,
and each gate requires a programmable bootstrap (PBS) to refresh
ciphertext noise. The PBS rate is therefore the hard ceiling on the
private path. At this paper's parameters---$\sim$12ms per bootstrapped
gate on a single core---a GPU bootstrap kernel sustains only
\textbf{single- to double-digit full PBS operations per second per GPU}.
This is eight to ten orders of magnitude below a cleartext CLOB matcher,
which fills at up to 12.76\,B orders per second per GPU (9.13\,B on an
NVIDIA GB10) on the public D-Chain path (Lux Lightspeed DEX). The privacy
multiple is the gap between those two rates.
Two engineering consequences follow:
\begin{itemize}[leftmargin=2em,nosep]
\item \textbf{Batched per market.} Bootstraps are amortized by
batching all encrypted orders for a single market into one
homomorphic matching pass, rather than evaluating order-by-order.
The PBS kernel processes the batch; the per-order cost falls toward
the per-gate floor as the batch fills the GPU.
\item \textbf{P3Q-attested receipts.} Each matched trade receipt that
leaves the FHE+MPC pipeline is attested with a P3Q ML-DSA-65
threshold signature before settlement, so the settlement chain
verifies correctness without re-running the homomorphic matcher. The
ML-DSA-65 verify path is measured at $\sim$4{,}714 verifies per
second; verification is not the bottleneck---the bootstrap is.
\end{itemize}
The operative conclusion for system design: the FHE+MPC private path is
\emph{not} a drop-in replacement for the public CLOB. It is the correct
substrate for low-frequency, value-bearing private markets (dark-pool
crossing, treasury rebalancing, confidential securities) where the
seven-order-of-magnitude throughput cost buys order-book secrecy that no
cleartext matcher can offer. High-frequency markets stay on the public
cleartext D-Chain path.