From user transaction to settled state
A user submits a transaction to an endpoint or sequencer. The sequencer orders transactions into L2 blocks and may provide a fast preliminary confirmation. Batch data or commitments are published to a data-availability layer. Independent nodes derive the same L2 inputs, execute them, and compute state roots. A settlement mechanism then decides when another chain should accept those results.
The execution engine may be EVM-compatible, WASM-based, or custom. Its surrounding pipeline determines whether users can reconstruct the chain, challenge an invalid result, force inclusion, and withdraw when privileged infrastructure fails.
Sequencing and derivation
Sequencing controls ordering and therefore affects latency, censorship resistance, and extractable value. A centralized sequencer can deliver a smooth experience but creates an operational dependency. Architecture reviews should identify fallback paths, forced-transaction mechanisms, outage behavior, and who can change sequencing rules.
Derivation is the deterministic process that reads published data and reconstructs execution inputs. This layer often normalizes deposits, system transactions, batch formats, and protocol upgrades. A node should be able to derive the same chain from the agreed data source without trusting the sequencer's private database.
Data availability is not the same as execution
Execution proves or computes what transactions do; data availability determines whether the inputs needed to reconstruct the chain can be retrieved. Posting full data to a base layer offers one trust model. Alternative data-availability systems may reduce cost but introduce different assumptions and recovery procedures.
A state root alone is not enough for ordinary users to recover account histories or generate challenges. The design must make the relevant transaction and state-transition data available for the period in which verification or dispute is required.
Fault proofs and validity proofs
Optimistic systems accept proposed results unless someone successfully challenges them. Their security depends on at least one capable, incentivized participant being able to reconstruct execution and submit a fault proof within the allowed window. The VM needs a dispute mechanism that can isolate disagreement to a verifiable step.
Validity systems attach a proof that the transition satisfied the rules. Verification can be fast, but proof generation adds computation, specialized infrastructure, and circuit or zkVM constraints. Hybrid designs may use validity proofs for some components and delayed challenges for others.
Operational questions for a rollup VM
- Can an independent node derive the chain from public inputs?
- What happens when the sequencer is offline or censoring?
- Where is transaction data published, and for how long is it retrievable?
- Which execution client and VM version define the state transition?
- Who can upgrade the derivation rules, bridge, verifier, or execution engine?
- How are invalid state roots challenged or rejected?
- What user escape or forced-withdrawal path exists?
- Which stage gives a user economic finality for a particular action?
Read the detailed rollup execution environments guide and compare proof choices in the zkVM overview.