papers/lux-zap-wire-protocol.tex

\documentclass[11pt,letterpaper]{article}
\usepackage{shared/luxcover}
\usepackage[utf8]{inputenc}
\usepackage{amsmath,amssymb,amsfonts,amsthm}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{booktabs}
\usepackage{algorithm}
\usepackage{algorithmic}
\usepackage{listings}
\input{shared/lstlang}

\hypersetup{colorlinks=true,linkcolor=black,citecolor=blue,urlcolor=blue}

\newtheorem{theorem}{Theorem}
\newtheorem{lemma}[theorem]{Lemma}
\newtheorem{definition}{Definition}

\title{ZAP: Zero-Allocation Binary Wire Protocol\\for Consensus Transport}

\author{
Lux Research\thanks{Corresponding author: [email protected]}\\
\textit{Lux Industries Inc}\\
\texttt{[email protected]}
}

\date{Original: 2023\quad|\quad Revised: February 2026}

\begin{document}

\luxcoverpage

\begin{abstract}
We present ZAP, a zero-allocation binary wire protocol designed for inter-node consensus communication. ZAP achieves 20.26 million transactions per second in batch mode (50 connections, batch size 1000) and 376,000 TPS in parallel streaming, with 8.7$\mu$s per-message latency on a single connection. The protocol uses fixed-size message framing with type-length-value encoding, Ed25519 message authentication, and optional PQ TLS 1.3 (X25519MLKEM768) for transport encryption. We prove that ZAP's message ordering guarantees preserve consensus safety under partial synchrony, and that the zero-allocation design eliminates GC pauses that cause consensus timeouts in garbage-collected runtimes. ZAP is deployed in production across the MPC threshold signing cluster, DEX matching engine, and Quasar consensus protocol.

\textbf{Keywords}: wire protocol, binary encoding, consensus transport, zero allocation, post-quantum TLS
\end{abstract}

\section{Introduction}

Blockchain consensus protocols require a transport layer with three properties:
\begin{enumerate}
    \item \textbf{Low latency}: Sub-millisecond message delivery for fast finality
    \item \textbf{Deterministic performance}: No GC pauses or allocation spikes
    \item \textbf{Authentication}: Every message cryptographically bound to its sender
\end{enumerate}

Existing solutions fall short: gRPC adds $\sim$100$\mu$s of protobuf serialization overhead. JSON-RPC wastes 60\%+ of bandwidth on field names. NATS introduces a broker hop. WebSocket adds HTTP upgrade negotiation.

ZAP eliminates all intermediaries. Nodes connect directly via TCP, authenticate with Ed25519 identity keys, and exchange fixed-format binary messages with zero heap allocation on the hot path.

\section{Protocol Specification}

\subsection{Message Format}

\begin{definition}[ZAP Frame]
A ZAP frame is a fixed-layout binary message:
\[
\underbrace{1}_{\text{type}} \| \underbrace{4}_{\text{length}} \| \underbrace{32}_{\text{sender ID}} \| \underbrace{N}_{\text{payload}} \| \underbrace{64}_{\text{Ed25519 sig}}
\]
Total overhead: 101 bytes per message (independent of payload size).
\end{definition}

\subsection{Message Types}

\begin{table}[h]
\centering
\begin{tabular}{lll}
\toprule
\textbf{Type Byte} & \textbf{Name} & \textbf{Usage} \\
\midrule
0x01 & Identity & Connection handshake \\
0x02 & Ping/Pong & Liveness check \\
0x3C (60) & MPCBroadcast & MPC pub/sub \\
0x3D (61) & MPCDirect & MPC point-to-point \\
0x3E (62) & MPCReady & Peer registry \\
0x40 (64) & MPCKeygen & DKG protocol \\
0x41 (65) & MPCSign & Signing protocol \\
0x42 (66) & MPCReshare & Key resharing \\
0x43 (67) & MPCResult & Session result \\
0x50 (80) & ConsensusVote & Consensus voting \\
0x51 (81) & ConsensusPropose & Block proposal \\
0x52 (82) & ConsensusCommit & Commit certificate \\
\bottomrule
\end{tabular}
\end{table}

\subsection{Zero-Allocation Design}

\begin{algorithm}
\caption{ZAP Message Read (Zero-Allocation)}
\begin{algorithmic}[1]
\REQUIRE TCP connection $\text{conn}$, pre-allocated buffer $\text{buf}[8192]$
\ENSURE Parsed message type, payload slice, verified sender
\STATE Read 5 bytes into $\text{buf}[0:5]$ \COMMENT{type + length}
\STATE $\text{msgType} \leftarrow \text{buf}[0]$
\STATE $\text{payloadLen} \leftarrow \text{BigEndian}(\text{buf}[1:5])$
\STATE Read $32 + \text{payloadLen} + 64$ bytes into $\text{buf}[5:]$
\STATE $\text{senderID} \leftarrow \text{buf}[5:37]$ \COMMENT{slice, no copy}
\STATE $\text{payload} \leftarrow \text{buf}[37:37+\text{payloadLen}]$ \COMMENT{slice, no copy}
\STATE $\text{sig} \leftarrow \text{buf}[37+\text{payloadLen}:]$
\IF{$\neg\text{Ed25519Verify}(\text{senderID}, \text{buf}[0:37+\text{payloadLen}], \text{sig})$}
    \RETURN $(\text{error}, \text{nil}, \text{nil})$
\ENDIF
\RETURN $(\text{msgType}, \text{payload}, \text{senderID})$
\end{algorithmic}
\end{algorithm}

\begin{theorem}[Zero-Allocation Hot Path]
The ZAP read/write path performs zero heap allocations for messages $\leq 8192$ bytes. All data is read into pre-allocated buffers and returned as sub-slices.
\end{theorem}

\begin{proof}
The buffer $\text{buf}$ is allocated once at connection establishment (not per-message). The \texttt{Read} syscall writes directly into this buffer. Payload and sender ID are returned as slice headers pointing into $\text{buf}$---no \texttt{make}, \texttt{append}, or \texttt{new} on the hot path. Go's escape analysis confirms: the slice headers remain on the stack. The Ed25519 verification uses a pre-allocated scratchpad. Verified with \texttt{go test -benchmem}: 0 allocs/op for messages $\leq$ buffer size.
\end{proof}

\begin{lemma}[GC Pause Elimination]
With zero allocations on the hot path, the Go garbage collector has no new objects to trace during consensus rounds. GC pauses are bounded by the allocation rate of non-consensus goroutines (logging, metrics), typically $<$100$\mu$s.
\end{lemma}

\section{Performance}

\subsection{Benchmarks}

\begin{table}[h]
\centering
\begin{tabular}{lrrr}
\toprule
\textbf{Configuration} & \textbf{Throughput} & \textbf{Latency} & \textbf{Allocs/op} \\
\midrule
Single connection & 114K TPS & 8.7$\mu$s & 0 \\
20 parallel connections & 376K TPS & 2.7$\mu$s & 0 \\
50 conns + batch 1000 & 20.26M TPS & 0.05$\mu$s & 0 \\
\midrule
gRPC (comparison) & 45K TPS & 22$\mu$s & 12 \\
JSON-RPC (comparison) & 18K TPS & 55$\mu$s & 28 \\
NATS (comparison) & 85K TPS & 11$\mu$s & 4 \\
\bottomrule
\end{tabular}
\end{table}

\begin{theorem}[Throughput Bound]
ZAP's maximum throughput is bounded by:
\[
T_{\max} = \min\left(\frac{B_{\text{NIC}}}{|\text{frame}|}, \frac{1}{\tau_{\text{verify}}}\right)
\]
where $B_{\text{NIC}}$ is the NIC bandwidth and $\tau_{\text{verify}}$ is the Ed25519 verification time. On 25Gbps NICs with 64-byte payloads, $T_{\max} \approx 24$M frames/sec, consistent with the 20.26M measured.
\end{theorem}

\subsection{Batch Mode}

\begin{algorithm}
\caption{ZAP Batch Send}
\begin{algorithmic}[1]
\REQUIRE Messages $m_1, \ldots, m_k$, connection $\text{conn}$
\ENSURE All messages sent as a single syscall
\STATE $\text{iov} \leftarrow$ gather vector of all frames
\FOR{$i = 1$ to $k$}
    \STATE $\text{iov}[i] \leftarrow \text{EncodeFrame}(m_i)$ \COMMENT{into pre-allocated ring buffer}
\ENDFOR
\STATE $\text{writev}(\text{conn.fd}, \text{iov})$ \COMMENT{single syscall via scatter-gather I/O}
\end{algorithmic}
\end{algorithm}

The \texttt{writev} syscall sends all frames in a single kernel transition, amortizing the syscall overhead across $k$ messages. With $k = 1000$, per-message syscall cost drops from $\sim$1$\mu$s to $\sim$1ns.

\section{Transport Security}

\subsection{PQ TLS 1.3}

ZAP connections are wrapped in TLS 1.3 with post-quantum hybrid key exchange:

\begin{enumerate}
    \item \textbf{X25519MLKEM768}: Hybrid classical + post-quantum (Go 1.24+ default)
    \item \textbf{SecP256r1MLKEM768}: Alternative hybrid for FIPS environments
    \item \textbf{SecP384r1MLKEM1024}: Maximum security variant
\end{enumerate}

\begin{theorem}[Dual-Layer Authentication]
ZAP provides two independent authentication layers:
\begin{enumerate}
    \item TLS certificate authentication (Ed25519 self-signed certs)
    \item Per-message Ed25519 signature verification
\end{enumerate}
An attacker must compromise both layers to inject a forged message. TLS prevents passive eavesdropping; per-message signatures prevent active injection even if TLS is broken.
\end{theorem}

\subsection{Deduplication}

\begin{definition}[Message Deduplication]
ZAP maintains a TTL-based deduplication map: $\text{seen}: \text{Hash}(\text{sender} \| \text{payload}) \mapsto \text{timestamp}$. Messages with hashes in $\text{seen}$ within the TTL window (default 10 minutes) are dropped. Cleanup runs every 2 minutes.
\end{definition}

\begin{theorem}[Replay Protection]
Under the deduplication scheme, a replayed message $m$ is accepted if and only if it arrives more than $\text{TTL}$ seconds after the original. For consensus protocols with round durations $\ll \text{TTL}$, replay is impossible within the same consensus round.
\end{theorem}

\section{Consensus Safety Preservation}

\begin{theorem}[Message Ordering and Safety]
Let $\Pi$ be a BFT consensus protocol safe under partial synchrony with message delay bound $\Delta$. ZAP's TCP-ordered delivery preserves $\Pi$'s safety if:
\begin{enumerate}
    \item ZAP delivers messages in FIFO order per connection (TCP guarantees this)
    \item ZAP's authentication rejects messages from non-validators
    \item ZAP's deduplication prevents double-counting votes
\end{enumerate}
\end{theorem}

\begin{proof}
Safety in BFT protocols requires that no two conflicting blocks are finalized. This depends on quorum intersection: $|Q_1 \cap Q_2| \geq 1$ honest node for any two quorums $Q_1, Q_2$. ZAP's authentication ensures only validator messages contribute to quorums (condition 2). FIFO ordering ensures a validator's messages arrive in the order sent (condition 1), preventing reordering that could create phantom votes. Deduplication ensures each vote is counted exactly once (condition 3). Since ZAP preserves the message delivery model assumed by $\Pi$, $\Pi$'s safety proof applies.
\end{proof}

\section{Deployment}

ZAP is deployed across three production systems:
\begin{itemize}
    \item \textbf{MPC cluster}: 3-node consensus, threshold signing (types 0x3C--0x43)
    \item \textbf{DEX matching engine}: Order broadcast, fill notification (types 0x50--0x52)
    \item \textbf{Quasar consensus}: Block proposal, voting, commit certificates
\end{itemize}

The ZapDB embedded database (fork of BadgerDB, since 2017) uses the same binary encoding principles for on-disk storage, providing consistent serialization across network and storage layers.

% Added 2025-04: ZAP bridge consensus
\subsection{Teleport Bridge Watcher Consensus}

ZAP serves as the inter-watcher communication layer for the Teleport cross-chain bridge. Each watcher node monitors deposit events on external chains (Bitcoin, Ethereum, Solana, TON) and broadcasts observations to the watcher quorum over ZAP.

\begin{enumerate}
    \item \textbf{Deposit event broadcast}: Watchers emit \texttt{MPCBroadcast} (0x3C) messages containing deposit proofs. Per-message latency is 8.7$\mu$s with zero allocations, ensuring deposit observations propagate before the next CGGMP21 signing round begins.
    \item \textbf{CGGMP21 threshold signing}: Signing rounds use \texttt{MPCSign} (0x41) for point-to-point shares and \texttt{MPCBroadcast} (0x3C) for commitment distribution. ZAP's FIFO ordering guarantees that round messages are processed in protocol order, a requirement for CGGMP21 correctness.
    \item \textbf{W3C DID identity}: Each watcher authenticates via a W3C Decentralized Identifier bound to an ML-DSA-65 post-quantum key pair, providing quantum-resistant identity independent of the Ed25519 transport signatures.
    \item \textbf{Quasar finality}: Threshold signature results (\texttt{MPCResult}, 0x43) are submitted to the Quasar consensus layer for finality certification before relay to the destination chain.
    \item \textbf{Spike handling}: ZAP's 20.26M TPS batch mode absorbs Bitcoin block deposit spikes (up to $\sim$4000 transactions per block) without backpressure on the signing pipeline.
\end{enumerate}

\section{Conclusion}

ZAP achieves 20.26M TPS with zero allocations, post-quantum transport encryption, and provable consensus safety preservation. It eliminates the serialization overhead of gRPC (4.5$\times$ faster), the bandwidth waste of JSON-RPC (11$\times$ faster), and the broker dependency of NATS (5$\times$ faster). The protocol is production-deployed across MPC, DEX, and consensus systems.

\bibliographystyle{plain}
\begin{thebibliography}{9}
\bibitem{zapdb} Jain, M. et al. \textit{BadgerDB: Fast Key-Value Store in Go}. Dgraph Labs, 2017.
\bibitem{quasar} Kelling, Z. \textit{Quasar Consensus: Dual-Certificate Quantum-Secure Finality}. Lux Industries, 2025.
\bibitem{mpc} Kelling, Z. and Seesahai, V. \textit{Universal Threshold Signatures}. Lux Industries Inc, 2021.
\end{thebibliography}

\end{document}