papers/zoo-web5-local-first.tex

\documentclass[twocolumn,11pt]{article}
\usepackage{shared/zoocover}
\usepackage[utf8]{inputenc}
\usepackage{amsmath,amssymb}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{algorithm}
\usepackage{algorithmic}
\usepackage[numbers]{natbib}
\usepackage{abstract}
\usepackage{booktabs}
\usepackage{xcolor}
\usepackage{listings}

\lstset{
  basicstyle=\ttfamily\footnotesize,
  breaklines=true,
  frame=single,
  numbers=left,
  numberstyle=\tiny,
}

\title{\textbf{Web5: Local-First Applications with Chain-Anchored Trust}}

\author{
Zoo Labs Foundation Research\thanks{[email protected]}\\
\textit{Zoo Labs Foundation \quad Lux Industries \quad Hanzo AI}\\
\texttt{[email protected]}
}

\date{April 2025}

\begin{document}
\maketitle

\begin{abstract}
We present Web5, an application architecture that combines local-first data ownership with blockchain-anchored trust. Unlike Web3 approaches that attempt to store application state on-chain, Web5 keeps mutable data in per-user encrypted SQLite shards, synchronizes across devices via Conflict-free Replicated Data Types (CRDTs), wraps encryption keys with post-quantum ML-KEM, and commits only Merkle roots and policy state to the chain. The result is a system with the user experience of local applications, the portability of decentralized identity, the security of cryptographic permissions, and the auditability of blockchain settlement. We describe a concrete implementation using the Lux Network's VM architecture (IdentityVM, KeyVM, ThresholdVM) as the trust plane, Hanzo Base as the local runtime, and ZAP as the transport protocol. The system achieves sub-10\textmu{}s sync latency, per-user data isolation via deterministic key derivation (HMAC-SHA256 DEK/KEK hierarchy), and offline-first operation with eventual consistency. We provide formal definitions, a reference SDK with 18 passing tests, and deployment configurations for the Zoo Network as a reference application.
\end{abstract}

\section{Introduction}

The evolution of web application architectures can be characterized by where state lives and who controls trust:

\begin{itemize}
\item \textbf{Web1}: Read-only. State on the server. Trust by domain authority.
\item \textbf{Web2}: Read-write. State on someone else's servers. Trust by platform identity (OAuth, SAML).
\item \textbf{Web3}: Shared state on blockchains. Trust by consensus. But: slow, public, expensive for mutable app data.
\item \textbf{Web5}: User-owned local state. Portable identity. Cryptographic permissions. Chain-anchored interoperability.
\end{itemize}

The key insight is that blockchains are excellent as \textit{trust planes}---for identity, keys, policy, settlement, and audit---but poor as \textit{data planes} for the mutable, private, high-frequency state that applications actually need.

Web5 separates these concerns:

\begin{itemize}
\item \textbf{Data plane}: Encrypted SQLite shards, CRDT ops, blob storage, device cache, app workers.
\item \textbf{Trust plane}: DIDs, keys, policies, threshold approvals, Merkle anchors, payments, proofs.
\end{itemize}

This paper describes the architecture, implementation, and deployment of this model.

\section{Architecture}

\subsection{Personal Runtime}

Every user, organization, and application gets a local-first runtime:

\begin{enumerate}
\item Encrypted SQLite shard (one file per user/org)
\item CRDT synchronization log (conflict-free multi-device merge)
\item Local cache and indexes
\item Media and blob storage references
\item Device key material (DEK cached locally, zeroed on revocation)
\end{enumerate}

SQLite is an ideal unit of tenancy because it supports single-writer semantics (no contention between users), portable file format, and embedded operation without external dependencies~\cite{sqlite2020}.

\subsection{Key Hierarchy}

We employ a three-level key hierarchy:

\begin{align}
\text{OrgKEK} &= \text{HMAC-SHA256}(\text{MasterKEK}, \texttt{"vault:org:"} \| \text{orgID}) \\
\text{UserDEK} &= \text{HMAC-SHA256}(\text{OrgKEK}, \texttt{"vault:user:"} \| \text{userID})
\end{align}

The Master KEK resides in a Hardware Security Module (AWS KMS, GCP Cloud KMS, Azure Key Vault) or is threshold-reconstructed via the K-Chain's ML-KEM key governance. It never touches disk.

Each user's DEK encrypts their SQLite shard using AES-256-GCM with random 12-byte nonces per entry. This provides:

\begin{itemize}
\item \textbf{User isolation}: Compromising one DEK reveals only that user's data.
\item \textbf{Org isolation}: Different org KEKs produce different DEKs for the same user ID.
\item \textbf{Rotation}: Org KEK rotation requires only re-deriving DEKs and re-encrypting shard headers, not re-encrypting all row data.
\item \textbf{Revocation}: Zeroing a DEK from device memory immediately prevents further reads.
\end{itemize}

For post-quantum security, the Master KEK can be wrapped using ML-KEM-768 (NIST FIPS 203)~\cite{nist-mlkem} for key establishment between HSM, K-Chain validators, and user devices.

\subsection{CRDT Synchronization}

Multi-device access is enabled by Conflict-free Replicated Data Types (CRDTs). Our implementation provides:

\begin{itemize}
\item \textbf{GCounter / PNCounter}: Monotonic and bidirectional counters
\item \textbf{LWW-Register}: Last-writer-wins for scalar values
\item \textbf{OR-Set}: Observed-remove set with add-wins semantics
\item \textbf{MV-Register}: Multi-value register preserving concurrent writes
\item \textbf{Document}: Composable CRDT document with nested fields
\end{itemize}

Critically, CRDT operations carry \textit{ciphertext}, not plaintext. Sync peers relay opaque encrypted bytes without decrypting. Only the user's device (which holds the DEK after biometric/passkey unlock) can read the actual values.

\subsection{Chain Anchoring}

The chain stores only:

\begin{itemize}
\item DID / identity roots
\item Key handles and rotation events
\item Capability / policy state
\item Sync checkpoint Merkle roots
\item Audit receipts
\item Payment / metering records
\end{itemize}

A Merkle root is computed over the CRDT operation log:

\begin{equation}
\text{root} = \text{SHA-256}\left(\text{orgID} \| \text{userID} \| \bigoplus_{i=1}^{n} (\text{key}_i \| \text{ct}_i)\right)
\end{equation}

where $\text{ct}_i$ is the ciphertext of the $i$-th entry. This root is committed to the I-Chain (IdentityVM) as an anchor receipt, providing tamper-evidence without revealing data.

\subsection{On-Chain VMs}

The trust plane runs on three Lux Network VMs deployed as a private subnet:

\begin{itemize}
\item \textbf{I-Chain (IdentityVM)}: DIDs, verifiable credentials, OIDC sessions, anchor receipts. Supports \texttt{did:lux}, \texttt{did:web}, \texttt{did:key} methods.
\item \textbf{K-Chain (KeyVM)}: ML-KEM post-quantum key management. Stores key handles (never plaintext keys). Enforces rotation policy, access control, and audit logging.
\item \textbf{T-Chain (ThresholdVM)}: CGGMP21 (ECDSA), FROST (EdDSA), BLS threshold signing. JWTs are threshold-signed---no single signing key exists.
\end{itemize}

\section{SDK Design}

The SDK exposes five primitives:

\begin{enumerate}
\item \textbf{Identity}: \texttt{OpenUser(userID)} --- resolve DID, unwrap DEK, bind device.
\item \textbf{Key Access}: \texttt{GetShardKey()} --- unwrap via HSM or K-Chain threshold.
\item \textbf{Local DB}: \texttt{Put(key, value)}, \texttt{Get(key)}, \texttt{Delete(key)} --- encrypted SQLite.
\item \textbf{Sync}: \texttt{Sync()}, \texttt{Merge(ops)} --- CRDT over ZAP (8.7\textmu{}s RTT).
\item \textbf{Anchor}: \texttt{Anchor()} --- Merkle root to chain, returns audit receipt.
\end{enumerate}

Usage is minimal:

\begin{lstlisting}[language=Go]
v, _ := vault.Open(vault.SDKConfig{
    DataDir:   "./data",
    MasterKEK: masterKey,
    OrgID:     "my-org",
})
session, _ := v.OpenUser("alice")
session.Put("prefs", []byte(`{"theme":"dark"}`))
session.Sync()
receipt, _ := session.Anchor()
\end{lstlisting}

\section{The Firebase Replacement}

Web5 replaces centralized Backend-as-a-Service:

\begin{center}
\begin{tabular}{ll}
\toprule
\textbf{Firebase} & \textbf{Web5} \\
\midrule
Auth & DID + capability/session gateway \\
Firestore & Encrypted SQLite shard \\
Offline sync & CRDT \\
Storage & Content-addressed blob store \\
Functions & Workers on CRDT ops / chain receipts \\
\bottomrule
\end{tabular}
\end{center}

The migration path is: Firebase app $\to$ local-first app with chain-anchored trust. Not: Firebase app $\to$ smart contracts everywhere.

\section{Security Analysis}

\subsection{Key Compromise}

If a user's DEK is compromised, only that user's shard is exposed. The org KEK and other users' DEKs remain safe (HMAC-SHA256 is a PRF). Device revocation zeros the DEK immediately.

\subsection{Sync Privacy}

CRDT operations carry ciphertext. Relay nodes see encrypted bytes and metadata (key names, timestamps) but not values. For metadata privacy, key names can also be encrypted or hashed.

\subsection{Chain Minimality}

The chain never stores row data, keys, or plaintext. Merkle roots are commitments---they prove state integrity without revealing state content.

\subsection{Post-Quantum Readiness}

ML-KEM-768 wraps the Master KEK for distribution. Symmetric encryption (AES-256-GCM) is quantum-resistant by design. Threshold signing uses FROST (Ed25519) and CGGMP21 (secp256k1) today, with Corona (lattice-based) as the post-quantum threshold upgrade path.

\section{Implementation Status}

The system is implemented across multiple open-source repositories:

\begin{itemize}
\item \texttt{hanzoai/base} --- Hanzo Base framework with vault plugin (18 tests passing)
\item \texttt{luxfi/node} --- 14 VMs including IdentityVM, KeyVM, ThresholdVM (all building, tested)
\item \texttt{luxfi/hsm} --- Cloud HSM integration (AWS, GCP, Azure)
\item \texttt{luxfi/mpc} --- Threshold signing (CGGMP21, FROST, BLS)
\item \texttt{luxfi/zap} --- Zero-copy transport (8.7\textmu{}s latency)
\item \texttt{zooai/universe} --- Reference deployment with auth subnet
\end{itemize}

All code is open source under permissive licenses.

\section{Conclusion}

Web5 is not ``put apps on-chain.'' Web5 is ``put trust on-chain, keep state local, sync privately, and make identity portable.''

Every web2 application should become local-first, encrypted by default, user-portable, offline-capable, chain-auditable, permissionlessly hosted, and cryptographically interoperable. The architecture described here---per-user SQLite shards, CRDT sync, ML-KEM key wrapping, and chain anchoring---achieves this without sacrificing the performance, privacy, or usability that users expect.

The chain is the root of trust, settlement, and interoperability. Not the database.

\bibliographystyle{plainnat}
\begin{thebibliography}{9}
\bibitem{sqlite2020} R. Hipp, ``SQLite: Past, Present, and Future,'' \textit{Proc. VLDB Endow.}, vol. 15, no. 12, 2022.
\bibitem{nist-mlkem} NIST, ``Module-Lattice-Based Key-Encapsulation Mechanism Standard,'' FIPS 203, Aug. 2024.
\bibitem{shapiro2011} M. Shapiro et al., ``Conflict-Free Replicated Data Types,'' \textit{SSS 2011}, LNCS 6976, pp. 386--400.
\bibitem{kleppmann2019} M. Kleppmann et al., ``Local-First Software: You Own Your Data, in spite of the Cloud,'' \textit{Onward! 2019}.
\end{thebibliography}

\end{document}