papers/lp-210-block-stm/sections/01-introduction.tex

\section{Introduction}

This paper expands on LP-210 (\texttt{lps/LP-210-block-stm.md}) with
detail on the four-phase algorithm, the integration differences from
the original Aptos Block-STM \cite{blockstm2022}, the cross-shard
staged-prepare composition with LP-211, and the deterministic-output
proof that the same wave $+$ same prior root produces a byte-identical
post-wave root across Go and Rust validator implementations.

\subsection{What was wrong before}

A serial executor at the post-LP-209 wave layer is bounded by
single-thread throughput. For a securities-style workload (~30\%
read-only price queries, ~60\% account-disjoint transfers, ~10\%
contended order-book updates) the serial executor projected to
leave $\sim 75\%$ of a 16-core box idle. The waste compounds with
the LP-208 mempool throughput: projected aggregate admit rate at
\SI{1.28}{\mega tx/s} cannot be sustained if the executor commits
at projected $\sim$\SI{40}{\kilo tx/s} on one core. All numbers in
this paragraph are design-time estimates; end-to-end LP-210
execution was not exercised by the 2026-06-04 bench rounds.

\subsection{What this LP solves}

LP-210 executes the LP-209 wave in parallel via optimistic STM. Each
transaction in the wave is dispatched to one of $N$ goroutines
($N \leq$ core count). Each goroutine executes against a local
ZapDB snapshot, recording the read-set and write-set as it goes.
After all $N$ goroutines join, a commit phase detects conflicts via
version-vector intersection; conflicting transactions roll back via
LP-202 \texttt{txn.Discard()} and re-execute in dependency order;
non-conflicting transactions commit their MVCC diffs to the
next-wave ZapDB root atomically.

\subsection{Adaptations from the original Aptos Block-STM}

The original Aptos Block-STM \cite{blockstm2022} is a CPU-side
optimistic-STM executor over MoveVM's storage abstraction. Three
adaptations for this LP:

\begin{enumerate}[leftmargin=2em,nosep]
\item \textbf{ZapDB MVCC instead of MoveVM versioned storage.}
  Aptos's Block-STM uses MoveVM-specific version pointers; LP-210
  uses ZapDB's content-addressed MVCC version vectors directly. The
  intersection check is a hashmap probe over content-addressed
  versions, not a MoveVM-specific operation.
\item \textbf{ZAP buffer for tx-bytes.} Aptos's Block-STM operates
  on MoveVM bytecode; LP-210 operates on ZAP buffers shared by
  pointer across goroutines. The buffers are immutable; the only
  per-goroutine state is the read-set and write-set hashmaps.
\item \textbf{LP-202 atomic unwind primitives.} The original
  Block-STM uses its own rollback mechanism; LP-210 uses LP-202
  \texttt{txn.Discard()} for the rollback and the same \texttt{Commit()}
  for the atomic apply -- the same primitives that LP-205 pipelining
  and LP-211 cross-shard 2PC use. One unwind contract across the
  stack.
\end{enumerate}

The core mechanism -- optimistic execute, commit-phase conflict
detection, re-execute in dependency order -- is the Aptos Block-STM
construction.

\subsection{Block-STM vs Sealevel: detected vs declared}

\begin{table}[h]
\centering
\small
\begin{tabular}{@{}p{3.5cm}p{4cm}p{4cm}@{}}
\toprule
\textbf{Property} & \textbf{Sealevel (declared)} & \textbf{Block-STM (detected)} \\
\midrule
Submitter declares access set & required at tx submit & not required \\
False negatives (missed conflicts) & possible if declaration is wrong & impossible -- runtime detects \\
Overdeclared access sets & reduces parallelism & n/a \\
Re-execution cost & none & non-zero (conflicted txs re-execute serially) \\
Workload fit & account-model chains with statically known patterns & smart-contract chains with data-dependent access \\
Validator complexity & submitter-side complexity & submitter-side simplicity, runtime complexity \\
\bottomrule
\end{tabular}
\caption{Block-STM vs Sealevel.}
\label{tab:vs-sealevel}
\end{table}

Block-STM's runtime complexity is bounded by the MVCC primitives
ZapDB already provides for non-execution reasons (LP-202 speculative
execution shares the same machinery). The marginal complexity in
LP-210 is the conflict-detection hashmap and the re-execution
scheduler -- both small and well-tested.

LP-210 ships on a chain whose tx set is dominated by smart-contract
invocations whose access set is data-dependent (regulated securities
transfers gated on ERC-3643 compliance reads, identity registry
lookups). Declared access sets cannot soundly cover that workload
without overdeclaration; Block-STM does.