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