spec: fix typos (#2867)

Co-authored-by: Matthew Slipper <me@matthewslipper.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

specs/bridges.md

@@ -4,8 +4,9 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [Token Depositing](#token-depositing)
-- [Upgradability](#upgradability)
+- [Standard Bridges](#standard-bridges)
+  - [Token Depositing](#token-depositing)
+  - [Upgradability](#upgradability)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 

specs/deposits.md

@@ -22,18 +22,19 @@ with the authorization and validation conditions on L2.
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [The Deposited Transaction Type](#the-deposited-transaction-type)
+- [Deposits](#deposits)
+  - [The Deposited Transaction Type](#the-deposited-transaction-type)
     - [Source hash computation](#source-hash-computation)
     - [Kinds of Deposited Transactions](#kinds-of-deposited-transactions)
     - [Validation and Authorization of Deposited Transactions](#validation-and-authorization-of-deposited-transactions)
     - [Execution](#execution)
       - [Nonce Handling](#nonce-handling)
-- [L1 Attributes Deposited Transaction](#l1-attributes-deposited-transaction)
-- [Special Accounts on L2](#special-accounts-on-l2)
+  - [L1 Attributes Deposited Transaction](#l1-attributes-deposited-transaction)
+  - [Special Accounts on L2](#special-accounts-on-l2)
     - [L1 Attributes Depositor Account](#l1-attributes-depositor-account)
     - [L1 Attributes Predeployed Contract](#l1-attributes-predeployed-contract)
       - [L1 Attributes Predeployed Contract: Reference Implementation](#l1-attributes-predeployed-contract-reference-implementation)
-- [User-Deposited Transactions](#user-deposited-transactions)
+  - [User-Deposited Transactions](#user-deposited-transactions)
     - [Deposit Contract](#deposit-contract)
       - [Address Aliasing](#address-aliasing)
       - [Deposit Feed Contract: Reference Implementation](#deposit-feed-contract-reference-implementation)
@@ -254,8 +255,8 @@ feed contract][deposit-feed-contract] on L1.
 The deposit contract is deployed to L1. Deposited transactions are derived from the values in
 the `TransactionDeposited` event(s) emitted by the deposit contract.
 
-The deposit contract is responsible for maintaing the [guaranteed gas market](./guaranteed-gas-market.md),
-charging deposits for gas to be used on L2, and ensuring that the total amount of guaranted
+The deposit contract is responsible for maintaining the [guaranteed gas market](./guaranteed-gas-market.md),
+charging deposits for gas to be used on L2, and ensuring that the total amount of guaranteed
 gas in a single L1 block does not exceed the L2 block gas limit.
 
 The deposit contract handles two special cases:

specs/exec-engine.md

@@ -4,15 +4,16 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [Deposited transaction processing](#deposited-transaction-processing)
+- [L2 Execution Engine](#l2-execution-engine)
+  - [Deposited transaction processing](#deposited-transaction-processing)
     - [Deposited transaction boundaries](#deposited-transaction-boundaries)
-- [Engine API](#engine-api)
+  - [Engine API](#engine-api)
     - [`engine_forkchoiceUpdatedV1`](#engine_forkchoiceupdatedv1)
       - [Extended PayloadAttributesV1](#extended-payloadattributesv1)
     - [`engine_newPayloadV1`](#engine_newpayloadv1)
     - [`engine_getPayloadV1`](#engine_getpayloadv1)
-- [Networking](#networking)
-- [Sync](#sync)
+  - [Networking](#networking)
+  - [Sync](#sync)
     - [Happy-path sync](#happy-path-sync)
     - [Worst-case sync](#worst-case-sync)
 

specs/glossary.md

@@ -4,6 +4,7 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
+- [Glossary](#glossary)
 - [General Terms](#general-terms)
   - [Layer 1 (L1)](#layer-1-l1)
   - [Layer 2 (L2)](#layer-2-l2)
@@ -200,7 +201,7 @@ all deposit-related terms.
 
 Notably, a *deposit* can refer to:
 
-- A [deposited transaction][deposited] (on L2) that is part of a [deposite block][deposit-block].
+- A [deposited transaction][deposited] (on L2) that is part of a [deposit block][deposit-block].
 - A [depositing call][depositing-call] that causes a [deposited transaction][deposited] to be derived.
 - The event/log data generated by the [depositing call][depositing-call], which is what the [rollup driver] reads to
   derive the [deposited transaction][deposited].

specs/guaranteed-gas-market.md

@@ -4,9 +4,10 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [Gas Stipend](#gas-stipend)
-- [Limiting Guaranteed Gas](#limiting-guaranteed-gas)
-- [Rationale for burning L1 Gas](#rationale-for-burning-l1-gas)
+- [Guaranteed Gas Fee Market](#guaranteed-gas-fee-market)
+  - [Gas Stipend](#gas-stipend)
+  - [Limiting Guaranteed Gas](#limiting-guaranteed-gas)
+  - [Rationale for burning L1 Gas](#rationale-for-burning-l1-gas)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 

specs/introduction.md

@@ -4,20 +4,21 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [Foundations](#foundations)
+- [Introduction](#introduction)
+  - [Foundations](#foundations)
     - [What is Ethereum scalability?](#what-is-ethereum-scalability)
     - [What is an Optimistic Rollup?](#what-is-an-optimistic-rollup)
     - [What is EVM Equivalence?](#what-is-evm-equivalence)
     - [🎶 All together now 🎶](#-all-together-now-)
-- [Protocol Guarantees](#protocol-guarantees)
-- [Network Participants](#network-participants)
+  - [Protocol Guarantees](#protocol-guarantees)
+  - [Network Participants](#network-participants)
     - [Users](#users)
     - [Sequencers](#sequencers)
     - [Verifiers](#verifiers)
-- [Key Interaction Diagrams](#key-interaction-diagrams)
+  - [Key Interaction Diagrams](#key-interaction-diagrams)
     - [Depositing and Sending Transactions](#depositing-and-sending-transactions)
     - [Withdrawing](#withdrawing)
-- [Next Steps](#next-steps)
+  - [Next Steps](#next-steps)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 

specs/messengers.md

@@ -4,12 +4,13 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [Message Passing](#message-passing)
-- [Upgradability](#upgradability)
-- [Message Versioning](#message-versioning)
+- [Cross Domain Messengers](#cross-domain-messengers)
+  - [Message Passing](#message-passing)
+  - [Upgradability](#upgradability)
+  - [Message Versioning](#message-versioning)
     - [Message Version 0](#message-version-0)
     - [Message Version 1](#message-version-1)
-- [Backwards Compatibility Notes](#backwards-compatibility-notes)
+  - [Backwards Compatibility Notes](#backwards-compatibility-notes)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
@@ -19,7 +20,7 @@ the ability to replay cross domain messages and sit directly on top of the lower
 level system contracts responsible for cross domain messaging on L1 and L2.
 
 The `CrossDomainMessenger` is extended to create both an
-`L1CrossDomainMessenger` and well as a `L2CrossDomainMessneger`.
+`L1CrossDomainMessenger` and well as a `L2CrossDomainMessenger`.
 These contracts are then extended with their legacy APIs to provide backwards
 compatibility for applications that integrated before the Bedrock system
 upgrade.

specs/overview.md

@@ -4,12 +4,13 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [Architecture Design Goals](#architecture-design-goals)
-- [Components](#components)
+- [Optimism Overview](#optimism-overview)
+  - [Architecture Design Goals](#architecture-design-goals)
+  - [Components](#components)
     - [L1 Components](#l1-components)
     - [L2 Components](#l2-components)
     - [Transaction/Block Propagation](#transactionblock-propagation)
-- [Key Interactions In Depth](#key-interactions-in-depth)
+  - [Key Interactions In Depth](#key-interactions-in-depth)
     - [Deposits](#deposits)
     - [Block Derivation](#block-derivation)
       - [Overview](#overview)
@@ -56,7 +57,7 @@ deposits.
 token deposits (tokens are locked on L1, then minted on L2 via a deposited transaction).
 - **BatchInbox**: An L1 address to which the Batch Submitter submits transaction batches.
   - Transaction batches include L2 transaction calldata, timestamps, and ordering information.
-  - The BatchInbox is a regular EOA address. This lets us pass on gast cost savings by not executing any EVM code.
+  - The BatchInbox is a regular EOA address. This lets us pass on gas cost savings by not executing any EVM code.
 
 - **L2OutputOracle**: A smart contract that stores [L2 output roots](./glossary.md#l2-output) for use with withdrawals
 and fault proofs.
@@ -91,7 +92,7 @@ Since the EE uses Geth under the hood, Optimism uses Geth's built-in peer-to-pee
 propagate transactions. The same network can also be used to propagate submitted blocks and support snap-sync.
 
 Unsubmitted blocks, however, are propagated using a separate peer-to-peer network of Rollup Nodes. This is optional,
-however, and is provided as a convnience to lower latency for verifiers and their JSON-RPC clients.
+however, and is provided as a convenience to lower latency for verifiers and their JSON-RPC clients.
 
 The below diagram illustrates how the sequencer and verifiers fit together:
 
@@ -175,7 +176,7 @@ derivation function performs the following steps:
 3. Submits the payload attributes to the Engine API, where they are converted into blocks and added to the canonical
 chain.
 
-This process is then repeated with incrementing epohcs until the tip of L1 is reached.
+This process is then repeated with incrementing epochs until the tip of L1 is reached.
 
 ### Engine API
 

specs/predeploys.md

@@ -4,20 +4,21 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [Overview](#overview)
-- [OVM\_L2ToL1MessagePasser](#ovm%5C_l2tol1messagepasser)
-- [OVM\_DeployerWhitelist](#ovm%5C_deployerwhitelist)
-- [OVM\_ETH](#ovm%5C_eth)
-- [WETH9](#weth9)
-- [L2CrossDomainMessenger](#l2crossdomainmessenger)
-- [L2StandardBridge](#l2standardbridge)
-- [SequencerFeeVault](#sequencerfeevault)
-- [OptimismMintableTokenFactory](#optimismmintabletokenfactory)
-- [L1BlockNumber](#l1blocknumber)
-- [OVM\_GasPriceOracle](#ovm%5C_gaspriceoracle)
-- [Reserved System Address 1](#reserved-system-address-1)
-- [Reserved System Address 2](#reserved-system-address-2)
-- [L1Block](#l1block)
+- [Predeploys](#predeploys)
+  - [Overview](#overview)
+  - [OVM\_L2ToL1MessagePasser](#ovm_l2tol1messagepasser)
+  - [OVM\_DeployerWhitelist](#ovm_deployerwhitelist)
+  - [OVM\_ETH](#ovm_eth)
+  - [WETH9](#weth9)
+  - [L2CrossDomainMessenger](#l2crossdomainmessenger)
+  - [L2StandardBridge](#l2standardbridge)
+  - [SequencerFeeVault](#sequencerfeevault)
+  - [OptimismMintableTokenFactory](#optimismmintabletokenfactory)
+  - [L1BlockNumber](#l1blocknumber)
+  - [OVM\_GasPriceOracle](#ovm_gaspriceoracle)
+  - [Reserved System Address 1](#reserved-system-address-1)
+  - [Reserved System Address 2](#reserved-system-address-2)
+  - [L1Block](#l1block)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
@@ -161,7 +162,7 @@ interface iOVM_ETH {
 ```solidity
 interface WETH9 {
     function name() public returns (string);
-    funcion symbol() public returns (string);
+    function symbol() public returns (string);
     function decimals public returns (uint8);
 
     event  Approval(address indexed src, address indexed guy, uint wad);
@@ -254,7 +255,7 @@ interface iOVM_L1BlockNumber {
 The `OVM_GasPriceOracle` is pushed the L1 basefee and the L2 gas price by
 an offchain actor. The offchain actor observes the L1 blockheaders to get the
 L1 basefee as well as the gas usage on L2 to compute what the L2 gas price
-should be based on a congenstion control algorithm.
+should be based on a congestion control algorithm.
 
 Its usage to be pushed the L2 gas price by an offchain actor is deprecated in
 Bedrock, but it is still used to hold the `overhead`, `scalar`, and `decimals`
@@ -336,7 +337,7 @@ Reserved for future use.
 [l1-block-predeploy]: glossary.md#l1-block-predeployed-contract
 
 The [L1Block](l1-block-predeploy) was introduced in Bedrock and is responsible for
-mainting L1 context in L2. This allows for L1 state to be accessed in L2.
+maintaining L1 context in L2. This allows for L1 state to be accessed in L2.
 
 ```solidity
 interface L1Block {

specs/proposals.md

@@ -9,12 +9,13 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [Proposing L2 Output Commitments](#proposing-l2-output-commitments)
-- [L2 Output Commitment Construction](#l2-output-commitment-construction)
-- [L2 Output Oracle Smart Contract](#l2-output-oracle-smart-contract)
-- [Security Considerations](#security-considerations)
+- [L2 Output Root Proposals Specification](#l2-output-root-proposals-specification)
+  - [Proposing L2 Output Commitments](#proposing-l2-output-commitments)
+  - [L2 Output Commitment Construction](#l2-output-commitment-construction)
+  - [L2 Output Oracle Smart Contract](#l2-output-oracle-smart-contract)
+  - [Security Considerations](#security-considerations)
     - [L1 Reorgs](#l1-reorgs)
-- [Summary of Definitions](#summary-of-definitions)
+  - [Summary of Definitions](#summary-of-definitions)
     - [Constants](#constants)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->

specs/rollup-node-p2p.md

@@ -29,7 +29,8 @@ and are adopted by several other blockchains, most notably the [L1 consensus lay
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [P2P configuration](#p2p-configuration)
+- [Rollup-node P2P interface](#rollup-node-p2p-interface)
+  - [P2P configuration](#p2p-configuration)
     - [Identification](#identification)
     - [Discv5](#discv5)
       - [Structure](#structure)
@@ -50,7 +51,7 @@ and are adopted by several other blockchains, most notably the [L1 consensus lay
       - [Heartbeat and parameters](#heartbeat-and-parameters)
       - [Topic configuration](#topic-configuration)
       - [Topic validation](#topic-validation)
-- [Gossip Topics](#gossip-topics)
+  - [Gossip Topics](#gossip-topics)
     - [`blocks`](#blocks)
       - [Block encoding](#block-encoding)
       - [Block signatures](#block-signatures)

specs/rollup-node.md

@@ -44,6 +44,7 @@ currently only concerned with the specification of the rollup driver.
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
+- [Rollup Node Specification](#rollup-node-specification)
 - [L2 Chain Derivation](#l2-chain-derivation)
   - [From L1 Sequencing Window to L2 Payload Attributes](#from-l1-sequencing-window-to-l2-payload-attributes)
     - [Reading L1 inputs](#reading-l1-inputs)
@@ -329,7 +330,7 @@ after the L1 block that generated it. This is a duration of approximately 7 days
 as the "fault proof window", as after this time the block can no longer be challenged by a fault proof.
 
 L1 Ethereum reaches [finality][l1-finality] approximately every [12.8 minutes][consensus-time-params]. L2 blocks
-generated from finalized L1 blocksare "safer" than most recent L2 blocks because they will never disappear from the
+generated from finalized L1 blocks are "safer" than most recent L2 blocks because they will never disappear from the
 chain's history because of a re-org. However, they can still be challenged by a fault proof until the end of the fault
 proof window.
 

specs/withdrawals.md

@@ -33,17 +33,18 @@ finalization.
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
-- [Withdrawal Flow](#withdrawal-flow)
+- [Withdrawals](#withdrawals)
+  - [Withdrawal Flow](#withdrawal-flow)
     - [On L2](#on-l2)
     - [On L1](#on-l1)
-- [The L2ToL1MessagePasser Contract](#the-l2tol1messagepasser-contract)
-  - [Address Aliasing](#address-aliasing)
-- [The Optimism Portal Contract](#the-optimism-portal-contract)
-- [Withdrawal Verification and Finalization](#withdrawal-verification-and-finalization)
-- [Security Considerations](#security-considerations)
+  - [The L2ToL1MessagePasser Contract](#the-l2tol1messagepasser-contract)
+    - [Addresses are not Aliased on Withdrawals](#addresses-are-not-aliased-on-withdrawals)
+  - [The Optimism Portal Contract](#the-optimism-portal-contract)
+  - [Withdrawal Verification and Finalization](#withdrawal-verification-and-finalization)
+  - [Security Considerations](#security-considerations)
     - [Key Properties of Withdrawal Verification](#key-properties-of-withdrawal-verification)
     - [Handling Successfully Verified Messages That Fail When Relayed](#handling-successfully-verified-messages-that-fail-when-relayed)
-- [Summary of Definitions](#summary-of-definitions)
+  - [Summary of Definitions](#summary-of-definitions)
     - [Constants](#constants)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->