mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
f4ee7a0525
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.
98 lines
3.8 KiB
TeX
98 lines
3.8 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 "F-Chain MPC" / "F-Chain threshold governance" /
|
|
%% "F-Chain TFHE" / "F-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
|
|
%% ===================================================================
|
|
|
|
\documentclass[11pt,a4paper]{article}
|
|
\usepackage{../shared/luxcover}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage{amsmath,amssymb,amsfonts,amsthm}
|
|
\usepackage{graphicx}
|
|
\usepackage{hyperref}
|
|
\usepackage{algorithm}
|
|
\usepackage{algpseudocode}
|
|
\usepackage{booktabs}
|
|
\usepackage{enumitem}
|
|
\usepackage{tikz}
|
|
\usetikzlibrary{arrows.meta,positioning,shapes.geometric}
|
|
|
|
\newtheorem{theorem}{Theorem}[section]
|
|
\newtheorem{lemma}[theorem]{Lemma}
|
|
\newtheorem{proposition}[theorem]{Proposition}
|
|
\newtheorem{corollary}[theorem]{Corollary}
|
|
\newtheorem{definition}{Definition}[section]
|
|
\newtheorem{remark}{Remark}[section]
|
|
|
|
\hypersetup{
|
|
colorlinks=true,
|
|
linkcolor=black,
|
|
citecolor=blue,
|
|
urlcolor=blue
|
|
}
|
|
|
|
\title{\textbf{Lux as Trust Kernel:\\Identity, Key Policy, Threshold Governance,\\and Receipts}}
|
|
|
|
\author{
|
|
Lux Research\thanks{Corresponding author: [email protected]}\\
|
|
\textit{Lux Industries}\\
|
|
\texttt{[email protected]}
|
|
}
|
|
|
|
\date{2025}
|
|
|
|
\begin{document}
|
|
|
|
\luxcoverpage
|
|
|
|
\begin{abstract}
|
|
We formalize Lux Network as a \emph{trust kernel}: a minimal on-chain substrate that
|
|
provides identity binding, key lifecycle policy, threshold governance, and tamper-evident
|
|
receipts---without storing application data on-chain. The trust kernel model inverts the
|
|
common blockchain-as-database pattern. Applications retain full data sovereignty in local
|
|
encrypted vaults (capsules) while delegating exactly four concerns to the chain:
|
|
(i)~globally-unique identity via decentralized identifiers (\texttt{did:lux:*}),
|
|
(ii)~key registration and rotation policy on the K-Chain,
|
|
(iii)~quorum-controlled reveal and treasury approval on the F-Chain with TFHE policy
|
|
evaluation and CKKS confidential compute,
|
|
and (iv)~multi-party threshold signatures on the M-Chain via FROST and CGGMP21.
|
|
Every state transition produces a cryptographic receipt anchored on-chain, enabling
|
|
provider-independent auditability. We define the trust kernel formally, prove that it
|
|
preserves capsule sovereignty under Byzantine fault tolerance assumptions, and show
|
|
that the architecture enables cross-capsule coordination (key exchange, capability
|
|
delegation, threshold approval) without revealing plaintext to any single party.
|
|
All critical protocols are verified in Lean~4 against mechanized proofs for
|
|
consensus safety, FROST unforgeability, CGGMP21 threshold composition, and
|
|
trust authority delegation.
|
|
|
|
\textbf{Keywords}: trust kernel, decentralized identity, threshold governance,
|
|
key policy, receipt anchoring, post-quantum cryptography, TFHE, CKKS, FROST, CGGMP21
|
|
\end{abstract}
|
|
|
|
\tableofcontents
|
|
\newpage
|
|
|
|
%% ===================================================================
|
|
|
|
\input{sections/01-introduction}
|
|
\input{sections/02-k-chain-key-registry-and-policy}
|
|
\input{sections/03-f-chain-encrypted-policy}
|
|
\input{sections/04-m-chain-mpc-signing}
|
|
\input{sections/05-i-chain-decentralized-identity}
|
|
\input{sections/06-receipt-anchoring}
|
|
\input{sections/07-provider-accountability}
|
|
\input{sections/08-cross-capsule-coordination}
|
|
\input{sections/09-security-model}
|
|
\input{sections/10-formal-verification}
|
|
\input{sections/11-related-work}
|
|
\input{sections/99-conclusion}
|
|
|
|
\end{document}
|