mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekayandHanzo Dev
178febad68
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]>
136 lines
5.1 KiB
TeX
136 lines
5.1 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 "M-Chain MPC" / "M-Chain threshold governance" /
|
|
%% "M-Chain TFHE" / "M-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
|
|
%% ===================================================================
|
|
|
|
\section{Conclusion}
|
|
\label{sec:conclusion}
|
|
% ============================================================================
|
|
|
|
The Capsule is not a decentralized database. It is not a blockchain wallet.
|
|
It is not a privacy layer bolted onto an existing system.
|
|
|
|
The Capsule is a sovereign encrypted process. It is the unit of tenancy, the
|
|
unit of privacy, the unit of collaboration, and the unit of computation in
|
|
Web5. Every principal---human, organizational, algorithmic---gets one. The
|
|
vault holds state. The identity anchors trust. The capability set governs
|
|
access. The sync topology handles replication. The compute policy determines
|
|
where code runs. The audit chain proves what happened.
|
|
|
|
Base owns state: encrypted SQLite, CRDT sync, realtime APIs, plugin runtime.
|
|
Lux owns trust: identity on I-Chain, key policy on K-Chain, threshold reveals
|
|
on M-Chain, MPC signing on M-Chain, audit anchors on the primary network.
|
|
Providers own service quality: relay throughput, storage durability, compute
|
|
availability. Users own keys and exit rights: they can decrypt, revoke,
|
|
migrate, and audit at any time, without permission from any provider.
|
|
|
|
This is what it means for the personal computer to return---not as a device
|
|
on a desk, but as a cryptographic process that follows you across every device,
|
|
every application, and every provider. The Capsule is the personal computer
|
|
of Web5.
|
|
|
|
The hard problems remain hard. Key rotation UX is unsolved for multi-device
|
|
principals. Partial sharing requires schema-level compromises. Sync metadata
|
|
leaks to traffic analysis. Private search at scale is open. Agent memory
|
|
governance needs formal verification. Cross-app composition lacks a usable
|
|
consent flow.
|
|
|
|
We have listed these problems explicitly because solving them is the work
|
|
that matters. The architecture is sound. The cryptography is proven. The
|
|
chains are specified. What remains is the engineering and UX research to
|
|
make sovereignty invisible---to make it so natural that users never think
|
|
about keys, capabilities, or sync topologies, and yet own everything.
|
|
|
|
\bibliographystyle{plain}
|
|
\begin{thebibliography}{99}
|
|
|
|
\bibitem{kleppmann2019}
|
|
M.~Kleppmann, A.~Wiggins, P.~van Hardenberg, and M.~McGranaghan,
|
|
``Local-First Software: You Own Your Data, in Spite of the Cloud,''
|
|
\textit{Onward! 2019}, ACM, 2019.
|
|
|
|
\bibitem{solid2016}
|
|
T.~Berners-Lee and D.~Sambra,
|
|
``Solid: A Platform for Decentralized Social Applications Based on Linked Data,''
|
|
MIT CSAIL Technical Report, 2016.
|
|
|
|
\bibitem{fission2021}
|
|
B.~Holmgren and P.~Chiusano,
|
|
``UCAN: User Controlled Authorization Networks,''
|
|
Fission Specification, 2021.
|
|
|
|
\bibitem{ceramic2020}
|
|
M.~Zargham, J.~Clark, and D.~Buchner,
|
|
``Ceramic: A Decentralized Data Network for Web3 Applications,''
|
|
3Box Labs, 2020.
|
|
|
|
\bibitem{dxos2023}
|
|
R.~Brinkman et al.,
|
|
``DXOS: A Framework for Local-First Collaborative Applications,''
|
|
DXOS Technical Report, 2023.
|
|
|
|
\bibitem{evervault2022}
|
|
S.~Agarwal and C.~Sheridan,
|
|
``Evervault: Encryption as Infrastructure,''
|
|
Evervault Whitepaper, 2022.
|
|
|
|
\bibitem{lux-mchain-mpc}
|
|
Z.~Kelling and V.~Seesahai,
|
|
``M-Chain: Decentralized Multi-Party Computation Custody with Quantum-Safe Threshold Signatures,''
|
|
Lux Industries, 2023.
|
|
|
|
\bibitem{lux-tfhe}
|
|
Z.~Kelling,
|
|
``Torus Threshold Fully Homomorphic Encryption: Boolean Circuits on Encrypted Data with Distributed Decryption,''
|
|
Lux Industries, 2025.
|
|
|
|
\bibitem{lux-pq-crypto}
|
|
Z.~Kelling,
|
|
``Post-Quantum Cryptographic Suite for EVM: ML-KEM, ML-DSA, and SLH-DSA as Native Precompiles,''
|
|
Lux Industries, 2024.
|
|
|
|
\bibitem{lux-fhe-mpc-hybrid}
|
|
Z.~Kelling,
|
|
``Hybrid FHE-MPC Protocols for Multi-Input Confidential Computation on Lux,''
|
|
Lux Industries, 2025.
|
|
|
|
\bibitem{lux-id-did}
|
|
Z.~Kelling,
|
|
``Lux ID: Decentralized Identifier Specification for Multi-Chain Identity,''
|
|
Lux Industries, 2024.
|
|
|
|
\bibitem{lux-tokenomics}
|
|
Z.~Kelling,
|
|
``Lux Tokenomics: Economic Design for Multi-Chain Consensus Networks,''
|
|
Lux Industries, 2023.
|
|
|
|
\bibitem{shapiro2011}
|
|
M.~Shapiro, N.~Pregui\c{c}a, C.~Baquero, and M.~Zawirski,
|
|
``Conflict-Free Replicated Data Types,''
|
|
\textit{SSS 2011}, LNCS 6976, Springer, 2011.
|
|
|
|
\bibitem{nist-mlkem}
|
|
{National Institute of Standards and Technology},
|
|
``Module-Lattice-Based Key-Encapsulation Mechanism Standard,''
|
|
FIPS 203, 2024.
|
|
|
|
\bibitem{nist-mldsa}
|
|
{National Institute of Standards and Technology},
|
|
``Module-Lattice-Based Digital Signature Standard,''
|
|
FIPS 204, 2024.
|
|
|
|
\bibitem{sqlite2022}
|
|
R.~Hipp,
|
|
``SQLite: Past, Present, and Future,''
|
|
\textit{Proc. VLDB Endow.}, 15(12), 2022.
|
|
|
|
\end{thebibliography}
|
|
|