mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
6d75dc0464
Lux Partners Limited is not the entity behind this work. Every place the old name stood — copyright lines, site footers, brand config, legal and compliance text — now names the company that actually holds it. lux.fund is the exception and is not renamed to match: that site belongs to Lux Assets Management LLC, a different company, and it says so. Two kinds of line were left for a person rather than rewritten. A dated news item recording that Lux Partners Limited was established in the Isle of Man is a historical fact, and renaming it would falsify the record. And a sentence asserting that the company is domiciled in the Isle of Man is a claim about a jurisdiction, not a name — an Inc or an LLC is not an Isle of Man company, so swapping the name there would assert something untrue.
151 lines
8.0 KiB
TeX
151 lines
8.0 KiB
TeX
\section{Conclusion}
|
|
\label{sec:conclusion}
|
|
|
|
The Lux Interchain Transfer Protocol provides trustless token transfers with the following properties:
|
|
|
|
\begin{enumerate}
|
|
\item \textbf{Intra-Lux}: Sub-4-second transfers between appchains via BLS aggregate Warp proofs at minimal cost.
|
|
\item \textbf{Cross-ecosystem}: Light client verification on external chains with cryptographic trust, no committees.
|
|
\item \textbf{Atomicity}: Two-phase commit with HTLC ensures either both lock and mint succeed or neither does.
|
|
\item \textbf{Finality gadget}: External chains verify Lux finality via compact BLS or SNARK proofs.
|
|
\item \textbf{Defense-in-depth}: Rate limits and guardian monitoring contain potential exploits without adding trust assumptions.
|
|
\end{enumerate}
|
|
|
|
The protocol is deployed for intra-Lux transfers and under development for Ethereum and Cosmos bridges, with mainnet launch targeted for Q2 2025.
|
|
|
|
\subsection{Future Directions}
|
|
|
|
Several extensions are planned or under active development:
|
|
|
|
\begin{description}
|
|
\item[Intent-Based Cross-Chain Transfers.] Instead of specifying exact routing, users express transfer intents (source asset, destination asset, amount, maximum acceptable slippage). A solver network competes to fill intents optimally, selecting the cheapest routing across available bridges. The protocol settles via the existing lock-and-mint mechanism but abstracts routing complexity from users.
|
|
|
|
\item[Cross-Chain Liquidity Aggregation.] Fragmented liquidity across appchains reduces capital efficiency. A cross-chain liquidity layer would allow decentralized exchanges on different appchains to share order books via Warp messages. The aggregator collects signed quotes from multiple appchains and routes trades to the venue offering best execution, settling atomically via the two-phase commit protocol.
|
|
|
|
\item[Recursive SNARK Verification.] Current SNARK-based finality proofs require a single verification on the destination. Recursive SNARKs would enable composing multiple finality proofs (e.g., proving that appchain $A$'s finality was verified on appchain $B$, which was then verified on Ethereum) into a single constant-size proof. This enables trust-minimized multi-hop transfers where only the final destination performs verification.
|
|
|
|
\item[Programmable Bridge Hooks.] Extending the transfer protocol with pre- and post-transfer hooks that execute arbitrary logic on source and destination chains. For example, a pre-hook might swap the source token to the bridged denomination, while a post-hook might deposit the received tokens into a yield vault. Hooks are specified as contract addresses and calldata in the transfer message, executed atomically with the mint or release operation.
|
|
\end{description}
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{Comparison of cross-chain transfer approaches.}
|
|
\label{tab:bridgecompare}
|
|
\begin{tabular}{p{2.8cm}p{2cm}p{2cm}p{2cm}p{2.5cm}}
|
|
\toprule
|
|
\textbf{Property} & \textbf{Lux (Warp)} & \textbf{IBC} & \textbf{LayerZero} & \textbf{Wormhole} \\
|
|
\midrule
|
|
Trust model & Validator quorum & Light client & Oracle + relayer & Guardian set \\
|
|
Finality & Sub-4s & 6--12s & Chain-dependent & 13--19 min \\
|
|
Proof size & 48 B + bitmap & $\sim$1 KB & Variable & 64 B (multi-sig) \\
|
|
Atomicity & Two-phase commit & IBC ack & App-level & App-level \\
|
|
Rate limiting & Protocol-level & None & None & Governor \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
Lux's approach uniquely combines sub-second finality with protocol-level atomicity guarantees, eliminating the need for application-level retry logic that other bridge protocols require. The shared validator infrastructure between appchains provides a natural trust anchor that external bridge protocols cannot replicate.
|
|
|
|
\subsection{Operational Monitoring}
|
|
|
|
The bridge protocol exposes real-time health metrics for operational monitoring:
|
|
|
|
\begin{enumerate}
|
|
\item \textbf{Transfer latency}: End-to-end time from source lock to destination mint, measured per appchain pair.
|
|
\item \textbf{Relay success rate}: Percentage of messages successfully delivered on first attempt.
|
|
\item \textbf{Bridge balance invariant}: Continuous verification that total locked assets equal total minted assets, aggregated across all appchain pairs.
|
|
\item \textbf{Rate limit utilization}: Current consumption versus capacity per appchain pair, triggering alerts at 80\% utilization.
|
|
\end{enumerate}
|
|
|
|
These metrics are published to a shared observability layer, enabling cross-appchain monitoring dashboards and automated incident response. Anomaly detection triggers guardian alerts when any metric deviates by more than 3 standard deviations from its 24-hour rolling average.
|
|
|
|
\bibliographystyle{plain}
|
|
\begin{thebibliography}{30}
|
|
|
|
\bibitem{lux-bridge-2025}
|
|
Z.~Kelling and W.~Bin, ``Lux Bridge: Threshold-secured cross-chain communication with MPC custody, post-quantum verification, and formally verified contract invariants,'' Lux Industries, Inc., 2025.
|
|
|
|
\bibitem{zamyatin2021bridge}
|
|
A.~Zamyatin et al., ``SoK: Communication across distributed ledgers,'' in \emph{FC}, 2021.
|
|
|
|
\bibitem{ronin2022}
|
|
Ronin Network, ``Ronin bridge exploit post-mortem,'' 2022.
|
|
|
|
\bibitem{wormhole2022}
|
|
Wormhole, ``Wormhole bridge incident report,'' 2022.
|
|
|
|
\bibitem{goes2020ibc}
|
|
C.~Goes, ``The interblockchain communication protocol,'' \emph{arXiv:2006.15918}, 2020.
|
|
|
|
\bibitem{ethereumlc2022}
|
|
Ethereum Foundation, ``Sync committee light client protocol,'' \emph{EIP-4788 \& Altair}, 2022.
|
|
|
|
\bibitem{herlihy2018atomic}
|
|
M.~Herlihy, ``Atomic cross-chain swaps,'' in \emph{PODC}, 2018.
|
|
|
|
\bibitem{robinson2022crosschain}
|
|
P.~Robinson and R.~Hyland-Wood, ``Atomic crosschain transactions for Ethereum private sidechains,'' \emph{Blockchain: Research and Applications}, 2022.
|
|
|
|
\bibitem{succinct2023}
|
|
Succinct Labs, ``Telepathy: Trustless cross-chain communication via SNARK-verified light clients,'' 2023.
|
|
|
|
\bibitem{lee2023bridge}
|
|
Y.~Lee et al., ``SoK: Not quite water under the bridge,'' in \emph{IEEE S\&P}, 2023.
|
|
|
|
\bibitem{boneh2018compact}
|
|
D.~Boneh, M.~Drijvers, and G.~Neven, ``Compact multi-signatures for smaller blockchains,'' in \emph{ASIACRYPT}, 2018.
|
|
|
|
\bibitem{boneh2001bls}
|
|
D.~Boneh, B.~Lynn, and H.~Shacham, ``Short signatures from the Weil pairing,'' in \emph{ASIACRYPT}, 2001.
|
|
|
|
\bibitem{nakamoto2008bitcoin}
|
|
S.~Nakamoto, ``Bitcoin: A peer-to-peer electronic cash system,'' 2008.
|
|
|
|
\bibitem{buterin2014ethereum}
|
|
V.~Buterin, ``Ethereum: A next-generation smart contract and decentralized application platform,'' 2014.
|
|
|
|
\bibitem{kwon2016cosmos}
|
|
J.~Kwon and E.~Buchman, ``Cosmos: A network of distributed ledgers,'' 2016.
|
|
|
|
\bibitem{wood2016polkadot}
|
|
G.~Wood, ``Polkadot: Vision for a heterogeneous multi-chain framework,'' 2016.
|
|
|
|
\bibitem{groth2016size}
|
|
J.~Groth, ``On the size of pairing-based non-interactive arguments,'' in \emph{EUROCRYPT}, 2016.
|
|
|
|
\bibitem{kiayias2016proofs}
|
|
A.~Kiayias, A.~Miller, and D.~Zindros, ``Non-interactive proofs of proof-of-work,'' in \emph{FC}, 2020.
|
|
|
|
\bibitem{castro1999practical}
|
|
M.~Castro and B.~Liskov, ``Practical Byzantine fault tolerance,'' in \emph{OSDI}, 1999.
|
|
|
|
\bibitem{yin2019hotstuff}
|
|
M.~Yin et al., ``HotStuff: BFT consensus with linearity and responsiveness,'' in \emph{PODC}, 2019.
|
|
|
|
\bibitem{buchman2016tendermint}
|
|
E.~Buchman, ``Tendermint: Byzantine fault tolerance in the age of blockchains,'' Master's thesis, 2016.
|
|
|
|
\bibitem{gudgeon2020sok}
|
|
L.~Gudgeon et al., ``SoK: Layer-two blockchain protocols,'' in \emph{FC}, 2020.
|
|
|
|
\bibitem{bowe2017bls12381}
|
|
S.~Bowe, ``BLS12-381: New zk-SNARK elliptic curve construction,'' 2017.
|
|
|
|
\bibitem{galbraith2012}
|
|
S.~D.~Galbraith, ``Mathematics of public key cryptography,'' Cambridge University Press, 2012.
|
|
|
|
\bibitem{daian2020flash}
|
|
P.~Daian et al., ``Flash boys 2.0,'' in \emph{IEEE S\&P}, 2020.
|
|
|
|
\bibitem{saleh2021blockchain}
|
|
F.~Saleh, ``Blockchain without waste: Proof-of-stake,'' \emph{The Review of Financial Studies}, vol.~34, no.~3, pp.~1156--1190, 2021.
|
|
|
|
\bibitem{kiayias2017ouroboros}
|
|
A.~Kiayias et al., ``Ouroboros,'' in \emph{CRYPTO}, 2017.
|
|
|
|
\bibitem{lux-zap-2023}
|
|
Z.~Kelling, ``ZAP: Zero-allocation binary wire protocol for consensus transport,'' Lux Industries Inc, 2023.
|
|
|
|
\end{thebibliography}
|
|
|