doc: fix spec typos

specs/introduction.md

@@ -60,13 +60,13 @@ In order to scale Ethereum without sacrificing security, we must preserve 3 crit
 liveness, availability, and validity.
 
 1. **Liveness** - Anyone must be able to extend the rollup chain by sending transactions at any time.
-    - There are two ways transactions can be sent to the rollup chain: 1) via the sequencer, and 2) directly on layer
-2. The sequencer provides low latency & low cost transactions, while sending transactions directly to layer 1 provides
+    - There are two ways transactions can be sent to the rollup chain: 1) via the sequencer, and 2) directly on layer 1.
+The sequencer provides low latency & low cost transactions, while sending transactions directly to layer 1 provides
 censorship resistance.
-3. **Availability** - Anyone must be able to download the rollup chain.
+2. **Availability** - Anyone must be able to download the rollup chain.
     - All information required to derive the chain is embedded into layer 1 blocks. That way as long as the layer 1
 chain is available, so is the rollup.
-4. **Validity** - All transactions must be correctly executed and all withdrawals correctly processed.
+3. **Validity** - All transactions must be correctly executed and all withdrawals correctly processed.
     - The rollup state and withdrawals are managed on an L1 contract called the `L2 State Oracle`. This oracle is
 guaranteed to _only_ finalize correct (ie. valid) rollup block hashes given a **single honest verifier** assumption. If
 there is ever an invalid block hash asserted on layer 1, an honest verifier will prove it is invalid and win a bond.

specs/overview.md

@@ -26,7 +26,7 @@ This document assumes you've read the [introduction](./introduction.md).
 
 ## Architecture Design Goals
 
-- **Execution-Level EVM Equivalence:** The developer experience should be identical to L2 except where L2 introduces a
+- **Execution-Level EVM Equivalence:** The developer experience should be identical to L1 except where L2 introduces a
 fundamental difference.
   - No special compiler.
   - No unexpected gas costs.
@@ -137,7 +137,7 @@ Optimism's block derivation function is designed such that it:
 The rollup chain is subdivided into epochs. There is a 1:1 correspondence between L1 block numbers and epoch numbers.
 
 For L1 block number `n`, there is a corresponding rollup epoch `n` which can only be derived after a _sequencing window_
-worth of blocks haspassed, i.e. after L1 block number `n + SEQUENCING_WINDOW_SIZE` is added to the L1 chain.
+worth of blocks has passed, i.e. after L1 block number `n + SEQUENCING_WINDOW_SIZE` is added to the L1 chain.
 
 Each epoch contains at least one block. Every block in the epoch contains an L1 info transaction which contains
 contextual information about L1 such as the block hash and timestamp. The first block in the epoch also contains all

specs/rollup-node.md

@@ -72,4 +72,4 @@ The input and return types here are as defined by the [engine API specs][engine-
         OR `String` - one of `"safe"`, `"latest"`, or `"pending"`.
 - returns:
   1. `version`: `DATA`, 32 Bytes - the output root version number, beginning with 0.
-  1. `l2OutputRoot`: `DATA`, 32 Bytes - the output root
+  2. `l2OutputRoot`: `DATA`, 32 Bytes - the output root.