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]>
42 lines
1.9 KiB
TeX
42 lines
1.9 KiB
TeX
\section{Introduction}
|
|
|
|
|
|
\subsection{The Blockchain Data Access Problem}
|
|
|
|
Modern blockchain applications require rich, expressive queries over multi-chain state, but face a fundamental trilemma:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{On-chain queries}: Gas-efficient but limited expressiveness (no complex joins, aggregations, or graph traversal)
|
|
\item \textbf{External indexers}: Powerful queries but centralized trust assumptions and version skew
|
|
\item \textbf{Full node scanning}: Decentralized but prohibitively slow and resource-intensive
|
|
\end{itemize}
|
|
|
|
This problem becomes acute in multi-chain architectures like Lux Network, where applications need to query state across 8 specialized chains simultaneously.
|
|
|
|
\subsection{G-Chain Solution}
|
|
|
|
G-Chain solves this through a dedicated blockchain layer that:
|
|
|
|
\begin{enumerate}
|
|
\item \textbf{Indexes all chains}: Unified view of P, C, X, Q, Z, A, B, M, F chain state
|
|
\item \textbf{GraphQL interface}: Rich, standardized query language with type safety
|
|
\item \textbf{Horizontal scaling}: User-operated nodes with selective synchronization
|
|
\item \textbf{On-chain execution}: Gas-metered GraphVM for contract-accessible queries
|
|
\item \textbf{Quantum-safe auth}: Dual-certificate signatures (BLS + Pulsar)
|
|
\item \textbf{Deterministic state}: BadgerDB backend with synchronized compaction
|
|
\end{enumerate}
|
|
|
|
\subsection{Key Contributions}
|
|
|
|
This paper makes the following contributions:
|
|
|
|
\begin{enumerate}
|
|
\item A deterministic, high-performance graph database (lux/graphdb) using BadgerDB
|
|
\item GraphVM interpreter for gas-metered GraphQL execution on-chain
|
|
\item EVM precompiles (0x0B-0x11) for graph mutations and proof verification
|
|
\item Decentralized node architecture with selective sync and custom indexing
|
|
\item Performance benchmarks showing sub-10ms query latency at scale
|
|
\item Integration patterns for dApps, wallets, explorers, and DeFi protocols
|
|
\end{enumerate}
|
|
|