mirror of
https://github.com/hanzoai/papers.git
synced 2026-10-30 14:58:42 +00:00
zeekay
0d1d121451
Fix shared/ include paths to ../shared/ for 55 subdirectory papers so
that hanzocover.sty and lstlang.tex resolve when building from each
paper's own directory (the build pattern used by latexmk per paper).
Build fixes:
- hanzo-operative/sections/03-screen-understanding-pipeline.tex: move
\COMMENT from after \FOR{...} onto the \STATE line so the algorithmic
env doesn't mis-parse.
- hanzo-network-architecture (abstract + sections 04, 12, 13): escape
unicode mu (U+03BC) as $\mu$ for pdflatex.
- ntt-transform/sections/08-benchmark-results.tex: same mu escape.
All 55 Tier-2/3 papers now build clean with latexmk -pdf.
63 lines
2.3 KiB
TeX
63 lines
2.3 KiB
TeX
\section{Discussion}
|
|
|
|
|
|
\subsection{Design Trade-offs}
|
|
|
|
\subsubsection{PQC Key Sizes}
|
|
|
|
ML-KEM/ML-DSA keys are $5-10\times$ larger than classical counterparts, increasing storage and bandwidth. However, this is acceptable given:
|
|
\begin{itemize}
|
|
\item Keys are generated infrequently
|
|
\item Storage is cheap ($<$\$0.01/GB/month)
|
|
\item Quantum threat timeline (5-15 years) justifies overhead
|
|
\end{itemize}
|
|
|
|
\subsubsection{Consensus Throughput vs. Decentralization}
|
|
|
|
Local throughput (9M blocks/sec) drops to 3,500 in geographically distributed setting. This is expected due to:
|
|
\begin{itemize}
|
|
\item Network latency dominates consensus time
|
|
\item Wave consensus requires $k=20$ samples per decision
|
|
\item Trade-off favors safety over speed
|
|
\end{itemize}
|
|
|
|
\subsubsection{HLLM Complexity}
|
|
|
|
Physics-inspired routing adds 2.8ms overhead vs. simple random selection. Benefits justify cost:
|
|
\begin{itemize}
|
|
\item 15-30\% cost reduction via optimal model selection
|
|
\item Improved user experience through regime-aware routing
|
|
\item Adaptive learning without retraining models
|
|
\end{itemize}
|
|
|
|
\subsection{Future Work}
|
|
|
|
\subsubsection{SLH-DSA Integration}
|
|
|
|
SPHINCS+ (SLH-DSA) provides hash-based signatures without lattice assumptions. Future versions will support hybrid ML-DSA/SLH-DSA for algorithm agility.
|
|
|
|
\subsubsection{Hardware Acceleration}
|
|
|
|
FPGA/ASIC implementations of ML-KEM could reduce latency to $<$10$\mu$s, enabling PQC in ultra-low-latency applications.
|
|
|
|
\subsubsection{Federated Learning}
|
|
|
|
Extending HLLM to support decentralized model training across nodes while preserving privacy via secure aggregation.
|
|
|
|
\subsubsection{Zero-Knowledge Proofs}
|
|
|
|
zk-SNARKs for verifiable compute execution, enabling trustless verification of inference results without revealing model weights.
|
|
|
|
\subsection{Limitations}
|
|
|
|
\begin{enumerate}
|
|
\item \textbf{Quantum timeline uncertainty}: PQC overhead may be premature if quantum threat is $>$20 years away.
|
|
|
|
\item \textbf{HLLM tuning}: Regime detection thresholds require per-deployment tuning; no universal defaults.
|
|
|
|
\item \textbf{Cross-runtime compatibility}: Not all workloads portable across Docker/K8s/WASM without modification.
|
|
|
|
\item \textbf{Single-chain scaling}: Current architecture limited to single consensus chain; sharding not yet implemented.
|
|
\end{enumerate}
|
|
|