mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
Restructured from flat .tex/.pdf files into per-paper subdirectories. Added Antje Worring as co-author on all papers. Synced PDFs to pdfs/ for download site.
75 lines
2.7 KiB
TeX
75 lines
2.7 KiB
TeX
\section{Appchain State Sync}
|
|
\label{sec:appchain}
|
|
|
|
\subsection{Multi-Chain Sync Coordination}
|
|
|
|
New Lux nodes must synchronize state for the primary network and all appchains they validate. The sync coordinator manages parallel sync across chains:
|
|
|
|
\begin{algorithm}[H]
|
|
\caption{Multi-Chain Sync Coordinator}
|
|
\label{alg:coordinator}
|
|
\begin{algorithmic}[1]
|
|
\Require Chains to sync: $\{C_1, \ldots, C_m\}$ (primary + appchains)
|
|
\State Sort chains by priority: primary first, then appchains by validator obligation
|
|
\State Start primary network sync (Algorithm~\ref{alg:main})
|
|
\For{each appchain $C_k$ \textbf{in parallel} (up to $P_{\text{chains}}$ concurrent)}
|
|
\State Wait until primary network sync reaches height $h_k^{\text{min}}$
|
|
\State Begin appchain state sync using appchain-specific checkpoint
|
|
\State Use separate peer connections for each appchain
|
|
\EndFor
|
|
\State All syncs complete when all chains have verified roots
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
\subsection{Cross-Chain Checkpoint Consistency}
|
|
|
|
\begin{definition}[Consistent Multi-Chain Checkpoint]
|
|
A consistent checkpoint across chains $\{C_1, \ldots, C_m\}$ is a set of block heights $\{h_1, \ldots, h_m\}$ such that:
|
|
\begin{enumerate}
|
|
\item Each $h_k$ is finalized on chain $C_k$.
|
|
\item All cross-chain messages emitted before $h_k$ on any chain are received before $h_j$ on the destination chain.
|
|
\end{enumerate}
|
|
\end{definition}
|
|
|
|
This ensures that the synced state is globally consistent---no ``in-flight'' cross-chain messages are lost.
|
|
|
|
\subsection{Storage Requirements}
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{Storage requirements after state sync completion.}
|
|
\label{tab:storage}
|
|
\begin{tabular}{lrr}
|
|
\toprule
|
|
\textbf{Data Type} & \textbf{Size (C-Chain)} & \textbf{Notes} \\
|
|
\midrule
|
|
Account state (flat) & 42 GB & All accounts \\
|
|
Trie nodes & 36 GB & Internal nodes for verification \\
|
|
Contract code & 8 GB & Deduplicated \\
|
|
Recent blocks (1000) & 2 GB & For reorganization handling \\
|
|
\midrule
|
|
\textbf{Total} & \textbf{88 GB} & Minimal node after sync \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
State sync reduces initial storage from 200+ GB (full archive with all historical state) to 88 GB (current state only).
|
|
|
|
\subsection{Pruning After Sync}
|
|
|
|
After state sync, nodes can prune historical trie nodes no longer needed:
|
|
|
|
\begin{algorithm}[H]
|
|
\caption{Post-Sync State Pruning}
|
|
\label{alg:prune}
|
|
\begin{algorithmic}[1]
|
|
\Require Recent state roots $\{R_{h-1000}, \ldots, R_h\}$ to retain
|
|
\State Mark all trie nodes reachable from retained roots
|
|
\State Delete all unmarked trie nodes
|
|
\State Compact database to reclaim space
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
Pruning reclaims approximately 30\% of storage, reducing the C-Chain node requirement from 88 GB to approximately 62 GB.
|
|
|