01 / term
Layer 2
A protocol that executes transactions outside Layer 1 and returns compressed state commitments, proofs, or dispute data to the base chain for settlement.
00 / abstract
Layer 2 systems relocate execution away from Ethereum mainnet while preserving a verifiable relationship to its settlement layer.
02 / term
Rollup
A Layer 2 construction that publishes enough data to reconstruct state and relies on either fraud proofs or validity proofs to bind off-chain execution to Layer 1.
03 / term
Data Availability
The guarantee that transaction data behind a state transition can be retrieved by validators, challengers, or independent observers when it matters.
04 / explanation
Rollup Architecture
Rollups separate transaction execution from final settlement. Users submit transactions to a sequencer; the sequencer orders them, computes the resulting state, and periodically posts a batch commitment to Ethereum. The base chain does not repeat every computation. It receives compact evidence that lets the wider network verify or challenge the claim.1
Optimistic rollups assume batches are correct until challenged during a dispute window. Validity rollups attach succinct cryptographic proofs to each batch, replacing social challenge games with mathematical verification. Both designs trade direct Layer 1 execution for a layered accountability model.
Example commitment: 0x4f2a9c1e8b77d3a0 / batch interval 12.8s / proof window 7d
05 / diagram
06 / term
Sequencer
An ordering service that collects transactions, produces batches, and gives users rapid pre-confirmations before final settlement is posted to Layer 1.
07 / term
Fraud Proof
A challenge mechanism that identifies an invalid state transition and replays the disputed computation on-chain to determine the canonical outcome.
08 / explanation
Optimistic Verification
The optimistic model is economical because the common case does not require immediate proof generation. Instead, any observer can inspect posted data and submit a challenge if a batch root is inconsistent with the transaction sequence. Security depends on at least one honest party watching the chain during the dispute period.2
This design gives optimistic systems broad virtual machine compatibility. The cost is latency: withdrawals to Layer 1 must wait long enough for disputes to be raised and resolved.
09 / distinction
Scaling is not a single mechanism; it is a taxonomy of where execution, data, ordering, and verification are placed.
10 / diagram
11 / explanation
State Channels
State channels move repeated interactions off-chain by locking assets into a contract and exchanging signed state updates between participants. The chain is invoked at opening, closing, or dispute time. When participants are online and cooperative, the channel behaves like a private high-frequency ledger.
The limitation is topology. Channels work best for known participants and bounded applications; they are less suitable for open, composable execution environments where arbitrary contracts must interact with arbitrary users.
12 / term
Validium
A validity-proof system that keeps transaction data off-chain, gaining throughput while depending on an external committee or data layer for availability.
13 / explanation
Validity Proof Systems
Validity rollups prove that a state transition was computed correctly without requiring every validator to recompute it. A prover generates a succinct proof, and an on-chain verifier contract checks that proof against the previous state root and public inputs. The result is immediate finality once the proof is accepted.
ZK-SNARKs and ZK-STARKs are the two dominant proof families. SNARKs typically emphasize small proofs and low verification cost; STARKs emphasize transparent setup assumptions and post-quantum leaning cryptographic primitives.3
14 / diagram
15 / matrix