1\documentclass[11pt]{article}
2\usepackage[utf8]{inputenc}
3\usepackage[margin=1in]{geometry}
4\usepackage{amsmath, amssymb, amsthm}
5\usepackage{booktabs}
6\usepackage{hyperref}
7\usepackage{listings}
8\usepackage{xcolor}
9
10\lstset{
11  basicstyle=\ttfamily\small,
12  keywordstyle=\color{blue}\bfseries,
13  commentstyle=\color{green!50!black}\itshape,
14  frame=single,
15  breaklines=true,
16  showstringspaces=false,
17}
18
19\newtheorem{theorem}{Theorem}[section]
20\newtheorem{definition}{Definition}[section]
21
22\title{Content-Addressable Storage for Version Control}
23\author{sublimated}
24\date{April 2026}
25
26\begin{document}
27\maketitle
28
29\begin{abstract}
30  We describe a content-addressable storage (CAS) system for version control
31  that uses BLAKE3 hashing to achieve deduplication, immutable history, and
32  efficient storage. The system supports multiple content formats including
33  LaTeX documents, which are compiled to both PDF and semantic HTML for
34  web-based review and collaboration.
35\end{abstract}
36
37\section{Introduction}
38
39Traditional version control systems store file snapshots or deltas indexed by
40revision numbers. Content-addressable storage takes a different approach: every
41piece of content is indexed by its cryptographic hash. This gives us three
42properties for free:
43
44\begin{enumerate}
45  \item \textbf{Deduplication.} Identical content is stored exactly once,
46    regardless of how many files or versions reference it.
47  \item \textbf{Immutability.} A content hash uniquely identifies a specific
48    version of a file. The content behind a hash can never change.
49  \item \textbf{Integrity.} Any corruption is immediately detectable by
50    recomputing the hash.
51\end{enumerate}
52
53\section{Hash Functions}
54\label{sec:hashing}
55
56The choice of hash function determines both performance and collision resistance.
57Table~\ref{tab:hashes} compares three common algorithms.
58
59\begin{table}[h]
60\centering
61\caption{Hash algorithm comparison}
62\label{tab:hashes}
63\begin{tabular}{lccc}
64  \toprule
65  Algorithm & Output (bits) & Speed (GB/s) & Collision resistance \\
66  \midrule
67  SHA-1     & 160 & 1.2 & Broken (SHAttered, 2017) \\
68  SHA-256   & 256 & 0.8 & Strong \\
69  BLAKE3    & 256 & 6.4 & Strong \\
70  \bottomrule
71\end{tabular}
72\end{table}
73
74We use BLAKE3~\cite{blake3} for all internal content addressing. Its $8\times$
75speed advantage over SHA-256 makes it practical for hashing large files in real
76time. SHA-1 is used only for git wire protocol compatibility.
77
78\subsection{Content Identifiers}
79
80Every blob is addressed by a self-describing content identifier (CID):
81
82\begin{lstlisting}
83blake3-a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a
84\end{lstlisting}
85
86The \texttt{blake3-} prefix identifies the hash algorithm, making the system
87extensible to future algorithms without ambiguity.
88
89\section{Storage Architecture}
90
91\begin{definition}
92  A \emph{content-addressable store} is a key-value store where the key for
93  any value $v$ is $H(v)$ for some cryptographic hash function $H$.
94\end{definition}
95
96The store supports three operations:
97
98\begin{itemize}
99  \item $\texttt{put}(v) \to H(v)$: store content, return its hash
100  \item $\texttt{get}(h) \to v$: retrieve content by hash
101  \item $\texttt{has}(h) \to \{0, 1\}$: check existence without fetching
102\end{itemize}
103
104\begin{theorem}
105  For a CAS with hash function $H$ of output length $n$ bits, the probability
106  of collision after inserting $k$ items is approximately
107  \begin{equation}
108    \label{eq:collision}
109    P(\text{collision}) \approx 1 - e^{-k^2 / 2^{n+1}}
110  \end{equation}
111  For $n = 256$ and $k = 10^{18}$ (an exabyte of unique files), this gives
112  $P \approx 10^{-41}$.
113\end{theorem}
114
115\section{LaTeX Compilation Pipeline}
116
117When a \texttt{.tex} file is pushed to sublimated, the compilation pipeline
118produces three outputs:
119
120\begin{enumerate}
121  \item \textbf{PDF} via \texttt{latexmk}: the canonical output for download
122    and journal submission.
123  \item \textbf{HTML} via LaTeXML: semantic HTML5 for web viewing with text
124    selection, search, and per-block comments.
125  \item \textbf{SVG pages} via \texttt{pdf2svg}: fallback rendering when
126    LaTeXML cannot process exotic packages.
127\end{enumerate}
128
129The HTML output is the primary web view. Each structural element (section,
130paragraph, theorem, figure) receives a stable ID, enabling comments to follow
131their blocks across edits.
132
133\subsection{Performance}
134
135Compilation time depends on document complexity:
136
137\begin{equation}
138  T_{\text{total}} = T_{\text{latexmk}} + T_{\text{LaTeXML}} + T_{\text{pdf2svg}}
139\end{equation}
140
141Typical values:
142\begin{itemize}
143  \item Simple document (no bibliography): 2--5s + 5--15s + 1s = 8--21s
144  \item With bibliography: 10--30s + 15--40s + 1s = 26--71s
145  \item Cached aux files reduce repeat compilations by $60\text{--}80\%$
146\end{itemize}
147
148\section{Conclusion}
149
150Content-addressable storage provides a natural foundation for version control.
151Combined with BLAKE3 hashing and dual-output LaTeX compilation, it enables
152a workflow where academic papers are versioned like code and reviewed like
153web documents.
154
155\bibliographystyle{plain}
156\bibliography{refs}
157
158\end{document}