doc: fix spec typos

CONTRIBUTING.md

@@ -6,7 +6,7 @@ There are plenty of ways to contribute, in particular we appreciate support in t
 
 - Reporting issues. For security issues see [Security policy](https://github.com/ethereum-optimism/.github/blob/master/SECURITY.md).
 - Fixing and responding to existing issues. You can start off with those tagged ["good first issue"](https://github.com/ethereum-optimism/optimism/contribute) which are meant as introductory issues for external contributors.
-- Improving the [community site](https://community.optimism.io/)[documentation](https://github.com/ethereum-optimism/community-hub) and [tutorials](https://github.com/ethereum-optimism/optimism-tutorial).
+- Improving the [community site](https://community.optimism.io/), [documentation](https://github.com/ethereum-optimism/community-hub) and [tutorials](https://github.com/ethereum-optimism/optimism-tutorial).
 - Become an "Optimizer" and answer questions in the [Optimism Discord](https://discord.optimism.io).
 - Get involved in the protocol design process by proposing changes or new features or write parts of the spec yourself in the [optimistic-specs repo](https://github.com/ethereum-optimism/optimistic-specs).
 

specs/deposits.md

@@ -58,7 +58,7 @@ byte sequence. The first version has `0x00` as the version byte and then as the
 
 [EIP-2718]: https://eips.ethereum.org/EIPS/eip-2718
 
-- `bytes32 sourceHash`: the source-hash, uniquely identifies the origin of the deposit
+- `bytes32 sourceHash`: the source-hash, uniquely identifies the origin of the deposit.
 - `address from`: The address of the sender account.
 - `address to`: The address of the recipient account, or the null (zero-length) address if the
   deposited transaction is a contract creation.

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.
+1. **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.
+1. **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
+  1. `l2OutputRoot`: `DATA`, 32 Bytes - the output root.