mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
b55171116e
Retract the fabricated '581M/597ns / 100M+/s / 434M GPU / planet-scale' headline (a time.Sleep sim + x40 fudge that measured nothing) across the corpus. Flagship lux-lightspeed-dex rewritten (decomplected d-chain engine / dexvm atomic proxy / Go wrapper / 0x9010 CLOB facade; measured GB10 104-126M & M4 Max ~250M fills/s byte-parity-gated; Knuth-D division lever; Block-STM settlement; P3Q->starkfri rollup to Z-Chain). Technical papers (precompile-engineering, gpu-crypto-stack, evmgpu-benchmark, p3q-corona, smart-order-routing, fhe-mpc-hybrid) carry the measured impl + cross-ref the flagship. >1B/s framed honestly as N-node aggregation, never single-GPU. All compile.
54 lines
2.8 KiB
TeX
54 lines
2.8 KiB
TeX
\section{Atomic Value Movement}
|
|
\label{sec:cross-chain}
|
|
|
|
Trading on the D-Chain requires moving value into and out of it from the public Lux
|
|
network. This is the responsibility of the atomic proxy (Section~\ref{sec:architecture}),
|
|
and it reuses the mechanism the Lux primary network already uses to exchange assets
|
|
between the X- and C-Chains: atomic shared-memory import/export, committed at block
|
|
acceptance. There is no external relayer trusted to move funds and no bridge holding
|
|
custody outside consensus.
|
|
|
|
\subsection{Shared-memory import/export}
|
|
|
|
A transfer between a public-network chain and the D-Chain is expressed as a matched
|
|
export/import pair applied atomically at \texttt{Block.Accept}:
|
|
|
|
\begin{algorithm}[H]
|
|
\caption{Atomic import into the D-Chain}
|
|
\begin{algorithmic}[1]
|
|
\STATE \textbf{Export} on the source chain: lock value and record an export to the
|
|
D-Chain's shared-memory address space.
|
|
\STATE \textbf{Relay}: the proxy carries the order and the pending import to the D-Chain.
|
|
\STATE \textbf{Apply at Accept}: when the D-Chain block is accepted, the matched
|
|
import/export is applied to shared memory in one commit---both legs take effect or
|
|
neither does.
|
|
\STATE \textbf{Settle}: fills from matching settle against the imported balance on the
|
|
D-Chain; the symmetric export path returns value to the source chain the same way.
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
Because the import and export are applied in a single shared-memory commit, value
|
|
conservation is structural: the proxy can lose its liveness (fail to relay) but it cannot
|
|
create or destroy value, and a block that is verified and then rejected applies nothing,
|
|
stranding no funds. The conservation property is exercised by an end-to-end test that
|
|
drives a transfer across the public chain, the proxy, and the D-Chain and asserts that
|
|
total balances are preserved all-or-nothing.
|
|
|
|
\subsection{Native asset convention}
|
|
|
|
For EVM compatibility the facade exposes native LUX as \texttt{address(0)} rather than a
|
|
wrapped token, matching the Uniswap-V4 native-currency convention. Wrapped liquidity, if
|
|
present, is a distinct asset---never the canonical key for native LUX. Internally the
|
|
canonical asset resolves to the D-Chain's native identity, so there is one representation
|
|
of native value on the matching path.
|
|
|
|
\subsection{Settlement cadence versus matching cadence}
|
|
|
|
Atomic value movement runs at block cadence: a transfer settles when a D-Chain block is
|
|
accepted, not per order. This is deliberate. The latency-critical leg is matching, which
|
|
is co-located inside the venue and measured in nanoseconds per fill
|
|
(Section~\ref{sec:gpu-matching}); the cross-chain settlement leg is the proxy's
|
|
responsibility and runs once per block. Separating the two---fast matching on-host, atomic
|
|
settlement at block cadence---keeps the hot path off the network relay, whose round-trip
|
|
would otherwise dominate per-order latency.
|