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]>
49 lines
2.7 KiB
TeX
49 lines
2.7 KiB
TeX
|
|
%% ===================================================================
|
|
%% LP-134 canonical naming (2025-12-15):
|
|
%% Per LP-134 (Lux Chain Topology), F-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)
|
|
%% F-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).
|
|
%% ===================================================================
|
|
|
|
\section{Agent Memory}
|
|
\label{sec:memory}
|
|
|
|
Agent memory is the persistent, private knowledge store that distinguishes a sovereign agent from a stateless API call. The memory system has three tiers.
|
|
|
|
\subsection{Local Vault Memory}
|
|
|
|
The primary memory store is the encrypted SQLite vault (Section~\ref{sec:capsule}). The agent writes structured key-value pairs, conversation histories, learned preferences, and intermediate reasoning artifacts. All writes are append-only with content-addressed keys:
|
|
|
|
\begin{equation}\label{eq:memory-key}
|
|
k = H(\text{namespace} \| \text{content})
|
|
\end{equation}
|
|
|
|
where $H$ is SHA-256. This ensures deduplication and enables efficient retrieval by content hash.
|
|
|
|
\subsection{CRDT-Synchronized Memory}
|
|
|
|
When an agent runs across multiple instances (e.g., horizontal scaling, migration between execution environments), memory consistency is maintained via Conflict-free Replicated Data Types (CRDTs)~\cite{shapiro2011crdts}. We use two CRDT structures:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{LWW-Register} (Last-Writer-Wins Register) for mutable configuration values.
|
|
\item \textbf{OR-Set} (Observed-Remove Set) for the agent's knowledge base, where entries can be independently added and removed across instances.
|
|
\end{itemize}
|
|
|
|
Synchronization occurs over encrypted channels between instances of the same capsule, authenticated by the capsule's DID. Cross-capsule memory is never synchronized---each capsule is a sovereignty boundary.
|
|
|
|
\subsection{FHE-Encrypted Memory}
|
|
|
|
For agents performing confidential reasoning---e.g., processing medical records, financial data, or proprietary strategies---the memory system supports Fully Homomorphic Encryption (FHE) using the CKKS scheme~\cite{cheon2017ckks}. The agent encrypts memory entries with its FHE public key:
|
|
|
|
\begin{equation}\label{eq:fhe-memory}
|
|
\tilde{m} = \text{CKKS.Enc}(\text{pk}_{\text{FHE}}, m)
|
|
\end{equation}
|
|
|
|
Encrypted memory can be processed by external compute nodes without decryption. The agent (or a threshold set of authorized parties via M-Chain) holds the decryption key.
|
|
|