mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-02 11:22:13 +00:00
Bylines, paper authorship, correspondence addresses and the founder blurb under each post named an individual. They name the organisation that published the work instead: the brand on posts and pages, the research byline on papers, and research@ in place of a personal address. Both are what these repositories already used elsewhere — nothing new was coined. Co-authors are untouched. Where a paper named someone else alongside, they stay named; only the one byline changed. Bibliography entries, running heads, PDF metadata and affiliations move with it, so a citation still resolves to whoever the cited paper names. Sample and fixture data uses the placeholder name these tests already use elsewhere, so no assertion changed meaning.
291 lines
12 KiB
TeX
291 lines
12 KiB
TeX
\documentclass[11pt,a4paper]{article}
|
|
\usepackage{shared/luxcover}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage{amsmath,amssymb,amsfonts,amsthm}
|
|
\usepackage{graphicx}
|
|
\usepackage{hyperref}
|
|
\usepackage{booktabs}
|
|
\usepackage{enumitem}
|
|
\usepackage{xcolor}
|
|
|
|
\hypersetup{colorlinks=true,linkcolor=black,citecolor=blue,urlcolor=blue}
|
|
|
|
\title{The Ethos of Lux\\[4pt]
|
|
\large Eight Principles for a Durable Blockchain Platform}
|
|
|
|
\author{
|
|
Lux Research\thanks{Corresponding author: [email protected]}\\
|
|
\textit{Lux Industries, Inc.}\\
|
|
\texttt{[email protected]}
|
|
}
|
|
|
|
\date{Original: January 2020\quad|\quad Revised: March 2026}
|
|
|
|
\begin{document}
|
|
|
|
\luxcoverpage
|
|
|
|
\begin{abstract}
|
|
This document codifies the eight design principles that have guided
|
|
every architectural decision in the Lux Network since its inception on
|
|
January 1, 2020. These principles are not technical
|
|
specifications---they are constraints on the solution space. Every
|
|
protocol, every API, every cryptographic choice in the Lux ecosystem
|
|
is evaluated against these principles before it ships.
|
|
\end{abstract}
|
|
|
|
\tableofcontents
|
|
\newpage
|
|
|
|
%% ============================================================
|
|
\section{Preamble}
|
|
|
|
Blockchain platforms fail for predictable reasons: they are too hard to
|
|
use, too brittle to extend, too slow to adapt, and too narrow to
|
|
interoperate. The Ethos of Lux exists to prevent those failure modes by
|
|
naming the properties we optimize for, in order of priority.
|
|
|
|
These principles were articulated as the Lux Network was founded on
|
|
January 1, 2020. They formalized constraints that were already implicit
|
|
in the earliest research---the lattice cryptography library
|
|
(\texttt{luxfi/lattice}, August 2019)~\cite{lux-lattice}, the quantum-resistant consensus
|
|
primitives~\cite{lux-consensus}, and the multi-party computation design~\cite{lux-mpc}. This revision adds,
|
|
for each principle, a single sentence mapping it to its production
|
|
realization as of March 2026.
|
|
|
|
%% ============================================================
|
|
\section{The Eight Principles}
|
|
|
|
\subsection{Approachability}
|
|
|
|
We want to enable anyone to be a blockchain developer. Lux provides an
|
|
intuitive set of APIs and libraries that cater to a wide array of
|
|
developer experience levels.
|
|
|
|
The barrier to entry for blockchain development remains unconscionably
|
|
high. Developers must learn new languages (Solidity, Move), new
|
|
execution models (gas, nonces, revert semantics), and new deployment
|
|
pipelines---all before writing a single line of business logic. Lux
|
|
treats developer experience as a first-class engineering objective,
|
|
not a documentation afterthought.
|
|
|
|
\medskip\noindent\textit{2026 status}: The Lux CLI provides one-command
|
|
chain creation, contract deployment, and validator management. The
|
|
\texttt{luxfi/sdk} supports Go, TypeScript, and Python with identical
|
|
API shapes.
|
|
|
|
\subsection{Availability}
|
|
|
|
As a payments-focused platform, we appreciate the necessity of
|
|
maintaining an extraordinarily high SLA. We provide the best possible
|
|
assurances in terms of reliable access to blockchain infrastructure
|
|
and ensure developers can count on our APIs to power their business.
|
|
|
|
A financial system that is intermittently available is not a financial
|
|
system. Lux targets five-nines availability at the RPC layer. This
|
|
drives every decision from consensus protocol design (Quasar's
|
|
leaderless architecture~\cite{lp105} eliminates single-point-of-failure leaders) to
|
|
infrastructure topology (multi-region validator sets with geographic
|
|
diversity requirements).
|
|
|
|
\medskip\noindent\textit{2026 status}: Quasar consensus (LP-020)
|
|
achieves sub-second finality with no leader election, eliminating
|
|
the availability cliff that leader-based protocols suffer under
|
|
validator churn.
|
|
|
|
\subsection{Composability}
|
|
|
|
As developers, we value small, modular tools and components that we can
|
|
assemble to solve any problem at hand. Our focus on composability
|
|
provides a simple system to reason about and a flexible platform for
|
|
solving problems.
|
|
|
|
Composability is the difference between a toolkit and a monolith. Every
|
|
Lux component---chains, VMs, precompiles, threshold signature
|
|
schemes---is designed to be used independently or in combination. A
|
|
developer can use the DEX orderbook~\cite{lp306} without the bridge, the MPC signer
|
|
without the DEX, the FHE library without the MPC signer. The AMM pools~\cite{lp308}
|
|
and the quantum network comparison framework~\cite{lp309} are similarly independent.
|
|
|
|
\medskip\noindent\textit{2026 status}: 19 EVM precompiles are
|
|
independently activatable at genesis. \texttt{luxfi/standard}~\cite{lux-standard} provides
|
|
composable Solidity contracts. \texttt{luxfi/mpc}~\cite{lux-mpc} supports CGGMP21,
|
|
FROST, and Pulsar~\cite{lux-corona} as independent protocol modules.
|
|
|
|
\subsection{Flexibility}
|
|
|
|
Our platform is designed to support extensive customization and is
|
|
adaptable to fit the needs of any business. We have used our libraries
|
|
and APIs to support a wide range of different businesses and business
|
|
models.
|
|
|
|
Flexibility without constraint is chaos. Lux provides flexibility
|
|
through well-defined extension points: custom VMs, pluggable consensus,
|
|
configurable precompile sets, and per-chain genesis parameters. The
|
|
invariant is that every extension point has exactly one way to use it.
|
|
|
|
\medskip\noindent\textit{2026 status}: White-label deployments
|
|
run sovereign L1 chains with custom token economics, branding, and
|
|
regulatory configurations---all on the same node binary compiled with
|
|
\texttt{-tags allvms}.
|
|
|
|
\subsection{Longevity}
|
|
|
|
We are dedicated to providing developers the most forward-looking
|
|
options available and are committed to building a platform that
|
|
developers can commit to using for years without fear of missing out
|
|
on cutting-edge technology.
|
|
|
|
Longevity means making bets that will still be correct in a decade.
|
|
Lattice-based cryptography over RSA. UTXO models where quantum
|
|
resistance matters. Leaderless consensus over leader-based. These are
|
|
not trend-chasing decisions---they are durability decisions.
|
|
|
|
\medskip\noindent\textit{2026 status}: Post-quantum cryptography
|
|
(ML-DSA, ML-KEM, Pulsar)~\cite{lp305} is deployed at the consensus layer, not
|
|
as a future upgrade path. Quasar's hybrid BLS + lattice design~\cite{lp105,lp307}
|
|
ensures the network is quantum-resistant today.
|
|
|
|
\subsection{Interoperability}
|
|
|
|
We want to free developers from caring about specific blockchain
|
|
implementations while affording them the flexibility to experiment
|
|
with as many different blockchain technologies as possible.
|
|
|
|
A blockchain that cannot talk to other blockchains is a database with
|
|
extra steps. Lux provides native cross-chain messaging (Warp), a
|
|
bridge architecture with MPC threshold signing (2-of-3, no single
|
|
point of compromise), and EVM compatibility for the largest existing
|
|
developer ecosystem.
|
|
|
|
\medskip\noindent\textit{2026 status}: Warp messaging with BLS
|
|
aggregation is live. The MPC bridge~\cite{lux-mpc} supports 15+ blockchain networks
|
|
via CGGMP21 (ECDSA) and FROST (EdDSA). EVM precompiles provide
|
|
in-protocol verification of cross-chain proofs.
|
|
|
|
\subsection{Security}
|
|
|
|
Especially given our focus and industry, security is of the utmost
|
|
importance. We believe decentralized solutions are inherently more
|
|
secure and have designed our architecture always with decentralization
|
|
and security foremost in our minds.
|
|
|
|
Security is not a feature---it is a property of every component. Lux
|
|
enforces defense in depth: post-quantum signatures at consensus,
|
|
threshold cryptography for key management, FHE for computation privacy,
|
|
and formal verification of the core consensus protocol. No single
|
|
compromise of any one layer grants an adversary access to user assets.
|
|
|
|
\medskip\noindent\textit{2026 status}: Three independent PQ signature
|
|
schemes (ML-DSA-65, SLH-DSA, Pulsar) are available as EVM
|
|
precompiles. The FHE library~\cite{lux-fhe} implements TFHE with
|
|
threshold key management. MPC wallets use 2-of-3 threshold signing.
|
|
|
|
\subsection{Scalability}
|
|
|
|
We want to remove barriers to widespread adoption of blockchain
|
|
technology in terms of both consumer friendliness and ability to
|
|
meet demand.
|
|
|
|
Scalability is not just transactions per second. It is the ability to
|
|
add capacity without redesigning the system. Lux achieves this through
|
|
horizontal chain creation (each application can run its own chain with
|
|
its own validator set), parallelized EVM execution, and a DAG-based
|
|
consensus structure that does not serialize all transactions through a
|
|
single leader.
|
|
|
|
\medskip\noindent\textit{2026 status}: The GPU-accelerated CLOB matching
|
|
engine sustains 9.13\,B byte-exact \texttt{uint256} orders/sec on an NVIDIA
|
|
GB10 and 12.76\,B on an AMD Radeon 8060S (5.60\,B on an Apple M4 Max, 2.80\,B
|
|
on an Apple M1 Max), byte-identical to the CPU reference~\cite{lp306}. Quasar
|
|
consensus scales linearly with validator count up to tested limits of 1,000
|
|
nodes.
|
|
|
|
%% ============================================================
|
|
\section{Epilogue}
|
|
|
|
These eight principles have not changed since 2020. What has changed
|
|
is the depth of their realization. In 2020, post-quantum security was
|
|
an aspiration; in 2026, it is a deployed consensus property
|
|
(Quasar~\cite{lp105}: BLS $\wedge$ ML-DSA $\wedge$ Pulsar, Christmas 2025).
|
|
In 2020, interoperability meant EVM compatibility; in 2026, it means
|
|
native cross-chain messaging (Warp) with threshold-signed bridge
|
|
transactions across 15+ blockchain networks~\cite{lux-mpc}.
|
|
|
|
The principles remain the filter. Every proposal, every pull request,
|
|
every architectural decision is evaluated against them. If a change
|
|
improves one principle without degrading another, it ships. If it
|
|
trades one principle for another, it requires explicit justification
|
|
and CTO sign-off.
|
|
|
|
The Ethos of Lux is not a marketing document. It is the engineering
|
|
constitution of the network. The full research archive~\cite{lux-papers} and formal
|
|
verification artefacts~\cite{lux-proofs} are publicly available.
|
|
|
|
%% ============================================================
|
|
|
|
\bibliographystyle{plain}
|
|
\begin{thebibliography}{9}
|
|
|
|
\bibitem{lp105}
|
|
Z.~Kelling, ``LP-020: Quasar --- Quantum-Secure Multi-Engine Consensus
|
|
with Triple-Proof Quantum Finality,'' Lux Industries, 2025.
|
|
|
|
\bibitem{lp305}
|
|
Z.~Kelling, ``LP-305: Quantum Secure Assets --- A Pioneering Methodology
|
|
for Lux Network in a Post-Quantum Age,'' Lux Industries, 2023 (rev.\ 2026).
|
|
|
|
\bibitem{lp306}
|
|
Z.~Kelling, ``LP-306: LX --- Decentralized Social Trading Exchange,''
|
|
Lux Industries, 2022 (rev.\ 2026).
|
|
|
|
\bibitem{lp307}
|
|
Z.~Kelling, ``LP-307: Quantum Consensus Protocol --- Eisenstein Series
|
|
and Lattice Signatures,'' Lux Industries, 2023 (rev.\ 2026).
|
|
|
|
\bibitem{lp308}
|
|
Z.~Kelling, ``LP-308: QuantumSwap --- Post-Quantum AMM with
|
|
Fungible/Non-Fungible Liquidity Pools,'' Lux Industries, 2024 (rev.\ 2026).
|
|
|
|
\bibitem{lp309}
|
|
Z.~Kelling, ``LP-309: Quantum Network --- Comparative Analysis of
|
|
Post-Quantum Resistance Across Blockchain Networks,'' Lux Industries,
|
|
2025 (rev.\ 2026).
|
|
|
|
\bibitem{lux-lattice}
|
|
\textit{luxfi/lattice}: Lattice-based cryptographic primitives (CKKS,
|
|
BFV, TFHE). Origin: August 2019. \url{https://github.com/luxfi/lattice}.
|
|
|
|
\bibitem{lux-fhe}
|
|
\textit{luxfi/fhe}: TFHE boolean-gate bootstrapping library with
|
|
threshold key management. \url{https://github.com/luxfi/fhe}.
|
|
|
|
\bibitem{lux-corona}
|
|
\textit{luxfi/corona}: Module-LWE threshold signature scheme (Ringtail-derived).
|
|
\url{https://github.com/luxfi/corona}.
|
|
|
|
\bibitem{lux-mpc}
|
|
\textit{luxfi/mpc}: Multi-party computation (CGGMP21 for ECDSA, FROST
|
|
for Ed25519). \url{https://github.com/luxfi/mpc}.
|
|
|
|
\bibitem{lux-standard}
|
|
\textit{luxfi/standard}: Composable Solidity contracts for the Lux EVM.
|
|
\url{https://github.com/luxfi/standard}.
|
|
|
|
\bibitem{lux-consensus}
|
|
\textit{luxfi/consensus}: Quasar consensus engine (BLS + ML-DSA +
|
|
Pulsar). \url{https://github.com/luxfi/consensus}.
|
|
|
|
\bibitem{lux-papers}
|
|
\textit{luxfi/papers}: Lux research paper archive.
|
|
\url{https://github.com/luxfi/papers}.
|
|
|
|
\bibitem{lux-proofs}
|
|
\textit{luxfi/proofs}: Formal verification artefacts (Lean 4, TLA+,
|
|
Tamarin, Halmos). \url{https://github.com/luxfi/proofs}.
|
|
|
|
\end{thebibliography}
|
|
|
|
\end{document}
|