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]>
44 lines
2.3 KiB
TeX
44 lines
2.3 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{Agent Attestation}
|
|
\label{sec:attestation}
|
|
|
|
Every agent action produces an attestation---a cryptographic proof of what the agent did, when, and under what authority. Attestations are the foundation of agent accountability.
|
|
|
|
\subsection{Action Receipts}
|
|
|
|
Each action generates a receipt:
|
|
\begin{equation}\label{eq:action-receipt}
|
|
\rho_a = \big(H(a), \text{did}(A), \kappa, t, \text{cost}(a), \sigma_A\big)
|
|
\end{equation}
|
|
|
|
where $H(a)$ is the hash of the action payload, $\kappa$ is the capability token authorizing the action, and $\sigma_A$ is the agent's signature. Receipts are stored in the agent's vault and periodically anchored to the C-Chain in Merkle batches.
|
|
|
|
\subsection{Audit Trails}
|
|
|
|
The full sequence of action receipts for a capsule forms a hash chain:
|
|
\begin{equation}\label{eq:audit-chain}
|
|
h_t = H(h_{t-1} \| \rho_{a_t})
|
|
\end{equation}
|
|
|
|
The chain head $h_t$ is published to the C-Chain at each settlement epoch. Any party with access to the receipt sequence can verify the chain's integrity by recomputing the hashes. The principal can audit the agent's complete action history at any time by requesting the receipt sequence from the vault.
|
|
|
|
\subsection{Proof-of-Work Receipts}
|
|
|
|
For computationally intensive tasks (model training, data processing, multi-step reasoning), the agent produces a proof-of-work receipt that attests to the computational effort expended. This is not proof-of-work in the mining sense---it is a verifiable computation receipt~\cite{gennaro2010verifiable} that binds the input, output, and computational trace:
|
|
|
|
\begin{equation}\label{eq:pow-receipt}
|
|
\rho_{\text{pow}} = \big(H(x), H(y), \text{trace\_root}, \text{steps}, t, \sigma_A\big)
|
|
\end{equation}
|
|
|