mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
abf99d05fc
Restructured from flat .tex/.pdf files into per-paper subdirectories. Added Antje Worring as co-author on all papers. Synced PDFs to pdfs/ for download site.
111 lines
4.1 KiB
TeX
111 lines
4.1 KiB
TeX
\section{Conclusion}
|
|
\label{sec:conclusion}
|
|
%% ===================================================================
|
|
|
|
Lux is not a database. Lux is a trust kernel.
|
|
|
|
This paper has formalized the trust kernel abstraction: the minimum on-chain
|
|
substrate that makes sovereign applications composable, auditable, and
|
|
provider-independent. The four chains---K (key policy), T (threshold governance),
|
|
M (MPC signing), I (decentralized identity)---provide exactly the trust services
|
|
that local encrypted vaults cannot provide on their own: global identity,
|
|
cross-party coordination, and settlement finality.
|
|
|
|
The trust kernel stores no application data. It stores commitments to
|
|
decisions about data. Every decision produces a receipt. Receipts are
|
|
permanent, tamper-evident, and verifiable by any party. This architecture
|
|
enables capsules to switch providers, delegate capabilities to other capsules,
|
|
and participate in threshold governance---all without revealing plaintext to
|
|
the chain or to each other.
|
|
|
|
The post-quantum migration path ensures that trust decisions made today remain
|
|
verifiable under future quantum adversaries. The mechanized Lean~4 proofs
|
|
provide formal guarantees for the critical protocol properties: consensus
|
|
safety, signature unforgeability, threshold composition security, and trust
|
|
delegation integrity.
|
|
|
|
The trust kernel is the answer to a question that the blockchain industry has
|
|
been asking incorrectly. The question is not ``how do we put data on-chain.''
|
|
The question is ``what is the minimum we must put on-chain so that everything
|
|
else can stay off-chain and still be trusted.'' Four things: identity, key
|
|
policy, threshold governance, and receipts.
|
|
|
|
%% ===================================================================
|
|
%% References
|
|
%% ===================================================================
|
|
|
|
\begin{thebibliography}{99}
|
|
|
|
\bibitem{lux-capsule-architecture}
|
|
Z.~Kelling.
|
|
\newblock Lux Capsule Architecture: Sovereign Encrypted Vaults with Trust Kernel Binding.
|
|
\newblock Lux Industries, 2026.
|
|
|
|
\bibitem{lux-mchain-mpc}
|
|
Z.~Kelling and V.~Seesahai.
|
|
\newblock M-Chain: Decentralized Multi-Party Computation Custody with Quantum-Safe Threshold Signatures.
|
|
\newblock Lux Industries, 2023.
|
|
|
|
\bibitem{lux-id-did-specification}
|
|
Z.~Kelling.
|
|
\newblock Lux ID: Decentralized Identity and Universal Access Management.
|
|
\newblock Lux Industries, 2020.
|
|
|
|
\bibitem{lux-pq-crypto-suite}
|
|
Z.~Kelling.
|
|
\newblock Post-Quantum Cryptographic Suite for EVM: ML-KEM, ML-DSA, and SLH-DSA as Native Precompiles.
|
|
\newblock Lux Industries, 2024.
|
|
|
|
\bibitem{lux-tfhe}
|
|
Z.~Kelling.
|
|
\newblock Torus Threshold Fully Homomorphic Encryption: Boolean Circuits on Encrypted Data with Distributed Decryption.
|
|
\newblock Lux Industries, 2025.
|
|
|
|
\bibitem{lux-warp-messaging}
|
|
Z.~Kelling.
|
|
\newblock Lux Warp Messaging: Cross-Chain Communication Protocol.
|
|
\newblock Lux Industries, 2023.
|
|
|
|
\bibitem{ucan-fission}
|
|
B.~Frazee, P.~Willison, and B.~Holmgren.
|
|
\newblock UCAN: User Controlled Authorization Networks.
|
|
\newblock Fission Codes, 2021.
|
|
|
|
\bibitem{ceramic-anchors}
|
|
J.~Clark, M.~Zargham, and D.~Rees.
|
|
\newblock Ceramic: A Decentralized Data Network for Web3.
|
|
\newblock 3Box Labs, 2022.
|
|
|
|
\bibitem{keybase}
|
|
M.~Krohn, M.~Mazieres, and C.~Coyne.
|
|
\newblock Keybase: Public Key Crypto for Everyone, Publicly Auditable Proofs of Identity.
|
|
\newblock Keybase, Inc., 2014.
|
|
|
|
\bibitem{signal-protocol}
|
|
T.~Perrin and M.~Marlinspike.
|
|
\newblock The X3DH Key Agreement Protocol.
|
|
\newblock Signal Foundation, 2016.
|
|
|
|
\bibitem{frost}
|
|
C.~Komlo and I.~Goldberg.
|
|
\newblock FROST: Flexible Round-Optimized Schnorr Threshold Signatures.
|
|
\newblock In \emph{Selected Areas in Cryptography (SAC)}, 2020.
|
|
|
|
\bibitem{cggmp21}
|
|
R.~Canetti, R.~Gennaro, S.~Goldfeder, N.~Makriyannis, and U.~Peled.
|
|
\newblock UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts.
|
|
\newblock In \emph{ACM CCS}, 2020.
|
|
|
|
\bibitem{mlkem}
|
|
NIST.
|
|
\newblock FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard.
|
|
\newblock National Institute of Standards and Technology, 2024.
|
|
|
|
\bibitem{mldsa}
|
|
NIST.
|
|
\newblock FIPS 204: Module-Lattice-Based Digital Signature Standard.
|
|
\newblock National Institute of Standards and Technology, 2024.
|
|
|
|
\end{thebibliography}
|
|
|