mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
Every rendered "T-Chain" / "ThresholdVM" / "teleportvm" reference across the paper corpus is rewritten to the correct canonical chain by concern: threshold signing / MPC / bridge custody / key recovery -> M-Chain (MVM); FHE / encrypted compute / threshold decryption -> F-Chain (FVM); teleport / cross-chain messaging -> B-Chain (bridgevm); consensus Pulsar stays Q-Chain. Section lux-trust-kernel/03-t-chain-threshold-governance.tex renamed -> 03-f-chain-encrypted-policy.tex (with \input + xref fixes). Braided "T-Chain" sections split by concern (M vs F). Only lp-020's chain-separation rationale and the shared lux/chains/thresholdvm library path retain the name, to record the removal. All changed papers rebuilt (pdflatex, rc=0, no undefined refs). §09 of lux-dao-governance-framework reframed: fabricated "production deployment" metrics ($50M/$240k/$12M, survey %s, "as of Oct 2024") relabeled as illustrative design configurations with no invented replacements; reality noted (DAO treasury is a 1/1 Safe); conclusion echo + one "first production" overclaim softened. This commit also captures concurrent corpus workstreams on the same tree. Co-authored-by: Hanzo Dev <[email protected]>
83 lines
4.9 KiB
TeX
83 lines
4.9 KiB
TeX
|
|
%% ===================================================================
|
|
%% LP-134 canonical naming (2025-12-15):
|
|
%% Per LP-134 (Lux Chain Topology), T-Chain has been split into:
|
|
%% M-Chain — MPC ceremonies for bridge custody of EXTERNAL wallets
|
|
%% (CGGMP21, FROST, Pulsar-general)
|
|
%% F-Chain — FHE compute + TFHE bootstrap-key generation (encrypted EVM)
|
|
%% T-Chain is REMOVED entirely; teleport is B-Chain (bridgevm, LP-6000). No teleportvm.
|
|
%% Where this paper says "T-Chain MPC" / "T-Chain threshold governance" /
|
|
%% "T-Chain TFHE" / "T-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
|
|
%% ===================================================================
|
|
|
|
\section{Introduction}
|
|
|
|
\label{sec:introduction}
|
|
|
|
The fundamental tension in distributed consensus is the CAP theorem~\cite{brewer2000cap}:
|
|
no system can simultaneously guarantee Consistency, Availability, and Partition tolerance.
|
|
Classical Byzantine Fault Tolerant (BFT) protocols such as PBFT~\cite{castro1999practical}
|
|
sacrifice availability under partition and exhibit $O(n^2)$ communication complexity, making
|
|
them impractical for networks with hundreds or thousands of validators.
|
|
Nakamoto consensus~\cite{nakamoto2008bitcoin}, used in Bitcoin and its descendants, achieves
|
|
probabilistic safety and scales to large validator sets, but requires minutes to hours for
|
|
practical finality due to its longest-chain fork resolution mechanism.
|
|
|
|
The metastable protocol family, first described in the original
|
|
paper~\cite{rocket2019wave}, introduced a fundamentally different approach: metastable
|
|
consensus through repeated stochastic sampling. Rather than relying on a designated leader
|
|
or all-to-all voting rounds, these protocols have each node repeatedly poll a small random
|
|
sample of peers and adopt the majority preference. This gossip-like mechanism achieves
|
|
emergent agreement in $O(\log n)$ rounds with only $O(kn)$ total message complexity, where
|
|
$k$ is the small sample size (typically 20--50 nodes).
|
|
|
|
Lux Consensus extends this foundation with four key innovations:
|
|
\begin{enumerate}
|
|
\item \textbf{DAG-based transaction ordering}: Transactions form a directed acyclic graph
|
|
rather than a linear chain, enabling parallel processing and conflict-free ordering without
|
|
global serialization.
|
|
\item \textbf{Adaptive confidence counters}: The protocol tracks consecutive rounds of
|
|
supermajority agreement, requiring $\beta$ consecutive rounds before finalizing, which
|
|
provides a tunable safety--liveness knob.
|
|
\item \textbf{Metastability-breaking}: We introduce a deterministic tie-breaking mechanism
|
|
grounded in verifiable random functions (VRFs) that resolves pathological configurations
|
|
where the system is evenly split between two preferences.
|
|
\item \textbf{Formal security proofs}: We provide the first rigorous proofs of Byzantine
|
|
fault tolerance for a metastable consensus protocol, establishing $f < n/3$ as the exact fault
|
|
tolerance threshold under our security model.
|
|
\end{enumerate}
|
|
|
|
\paragraph{Contributions.}
|
|
This paper makes the following contributions:
|
|
\begin{itemize}[nosep]
|
|
\item A complete specification of the Lux Consensus protocol, including the DAG layer,
|
|
Wave confidence mechanism, and VRF-based tie-breaking (\S\ref{sec:protocol}).
|
|
\item Formal proofs of safety, liveness, and convergence under partial synchrony with
|
|
up to $f < n/3$ Byzantine faults (\S\ref{sec:analysis}).
|
|
\item A detailed parameterization analysis relating $(k, \alpha, \beta)$ to security
|
|
margins and performance characteristics (\S\ref{sec:params}).
|
|
\item An empirical evaluation on a 1,000-node globally distributed testnet demonstrating
|
|
4,500+ TPS with 650ms median finality (\S\ref{sec:evaluation}).
|
|
\item A comprehensive security analysis covering long-range attacks, eclipse attacks,
|
|
Sybil resistance, and timing adversaries (\S\ref{sec:security}).
|
|
\item Machine-checked formal proofs in Lean~4 (Mathlib v4.14.0) covering all protocol
|
|
components, BFT thresholds, cryptographic primitives, and cross-chain delivery,
|
|
with 33 of 36 theorems fully proved (\S\ref{sec:formal}).
|
|
\end{itemize}
|
|
|
|
The remainder of this paper is organized as follows. Section~\ref{sec:background} reviews
|
|
related work across the metastable consensus family, classical BFT, and Nakamoto consensus.
|
|
Section~\ref{sec:model} establishes the system model and adversary assumptions.
|
|
Section~\ref{sec:protocol} presents the Lux protocol in detail.
|
|
Section~\ref{sec:analysis} provides formal safety, liveness, and convergence proofs.
|
|
Section~\ref{sec:params} analyzes parameterization.
|
|
Section~\ref{sec:implementation} describes the implementation.
|
|
Section~\ref{sec:evaluation} presents empirical evaluation.
|
|
Section~\ref{sec:security} analyzes security considerations.
|
|
Section~\ref{sec:formal} presents the Lean~4 formal verification results.
|
|
Section~\ref{sec:conclusion} concludes.
|
|
|
|
%% -----------------------------------------------------------------------
|
|
%% 2. BACKGROUND AND RELATED WORK
|
|
%% -----------------------------------------------------------------------
|