papers/lux-fraud-proofs/sections/02-optimistic-rollup-architecture.tex

\section{Optimistic Rollup Architecture}


The architecture of optimistic rollups on Lux follows a layered approach that separates execution, data availability, and verification concerns while maintaining tight integration with the base layer.

\subsection{Off-chain Execution}

Transaction execution occurs in a separate execution environment, either a dedicated Lux appchain or an external sequencer network. The executor, known as the sequencer, processes transactions according to deterministic rules and produces state transitions. This off-chain execution enables:

\begin{equation}
\text{Throughput}_{\text{rollup}} = \frac{\text{Sequencer Capacity}}{\text{State Update Frequency}}
\end{equation}

where sequencer capacity can be orders of magnitude higher than Layer 1 capacity due to the absence of consensus requirements.

\subsection{On-chain Data Availability}

While execution happens off-chain, all transaction data must be posted on-chain to ensure data availability. This guarantees that any party can reconstruct the state and verify claimed transitions. The data availability requirement ensures:

\begin{definition}[Data Availability]
A rollup maintains data availability if for every state transition $S_i \rightarrow S_{i+1}$, the transaction data $\mathcal{T}_i$ enabling this transition is accessible on-chain such that any party can compute $S_{i+1} = \text{STF}(S_i, \mathcal{T}_i)$ where STF is the state transition function.
\end{definition}

\subsection{State Root Assertions}

Sequencers periodically submit state root assertions to the Layer 1 contract, claiming that executing a specific set of transactions from a given state results in a new state. These assertions take the form:

\begin{equation}
A = \langle S_{\text{prev}}, S_{\text{new}}, \mathcal{T}, h, \sigma \rangle
\end{equation}

where $S_{\text{prev}}$ is the previous state root, $S_{\text{new}}$ is the claimed new state root, $\mathcal{T}$ is the transaction set, $h$ is the block height, and $\sigma$ is the asserter's signature.

\subsection{Challenge Period}

After an assertion is submitted, it enters a challenge period during which any party can dispute the claimed state transition. The challenge period $\tau$ must balance several factors:

\begin{equation}
\tau \geq \max(\tau_{\text{detect}}, \tau_{\text{prepare}}, \tau_{\text{network}}) + \tau_{\text{buffer}}
\end{equation}

where $\tau_{\text{detect}}$ is the time to detect fraud, $\tau_{\text{prepare}}$ is the time to prepare a challenge, $\tau_{\text{network}}$ accounts for network delays, and $\tau_{\text{buffer}}$ provides safety margin.