mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-03 05:07:46 +00:00
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]>
83 lines
4.1 KiB
TeX
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.
|
|
|