Lint & build fixes

specs/SUMMARY.md

@@ -54,6 +54,9 @@
       - [Derivation](./protocol/holocene/derivation.md)
       - [Execution Engine](./protocol/holocene/exec-engine.md)
       - [System Config](./protocol/holocene/system-config.md)
+    - [Isthmus](./protocol/isthmus/overview.md)
+      - [Execution Engine](./protocol/isthmus/exec-engine.md)
+      - [Superchain Config](./protocol/isthmus/superchain-config.md)
 - [Governance]()
   - [Governance Token](./governance/gov-token.md)
 - [Experimental]()

specs/protocol/isthmus/exec-engine.md

@@ -24,6 +24,11 @@
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
+<!-- All glossary references in this file. -->
+
+[l2-to-l1-mp]: ../../protocol/predeploys.md#L2ToL1MessagePasser
+[output-root]: ../../glossary.md#l2-output-root
+
 ## Overview
 
 The storage root of the `L2ToL1MessagePasser` is included in the block header's
@@ -38,7 +43,7 @@ is greater than or equal to the activation timestamp.
 
 ## `L2ToL1MessagePasser` Storage Root in Header
 
-After Isthumus hardfork's activation, the L2 block header's `withdrawalsRoot` field will consist of the 32-byte
+After Isthmus hardfork's activation, the L2 block header's `withdrawalsRoot` field will consist of the 32-byte
 [`L2ToL1MessagePasser`][l2-to-l1-mp] account storage root _after_ the block has been executed, and _after_ the
 insertions and deletions have been applied to the trie. In other words, the storage root should be the same root
 that is returned by `eth_getProof` at the given block number -- it is the storage root of the post state,
@@ -50,12 +55,12 @@ the state root attribute in the header.
 
 ### Header Validity Rules
 
-Prior to isthumus activation, the L2 block header's `withdrawalsRoot` field must be:
+Prior to isthmus activation, the L2 block header's `withdrawalsRoot` field must be:
 
 - `nil` if Canyon has not been activated.
 - `keccak256(rlp(empty_string_code))` if Canyon has been activated.
 
-After isthumus activation, an L2 block header's `withdrawalsRoot` field is valid iff:
+After isthmus activation, an L2 block header's `withdrawalsRoot` field is valid iff:
 
 1. It is exactly 32 bytes in length.
 1. The [`L2ToL1MessagePasser`][l2-to-l1-mp] account storage root, as committed to in the `storageRoot` within the block
@@ -81,7 +86,7 @@ for users and protocol participants alike, allowing them to propose and verify o
 
 #### Genesis Block
 
-If isthumus is active at the genesis block, the withdrawals root is the empty withdrawals root, regardless of L2 state.
+If isthmus is active at the genesis block, the withdrawals root is the empty withdrawals root, regardless of L2 state.
 
 #### State Processing
 
@@ -90,20 +95,20 @@ available to the EVM/application layer.
 
 #### P2P
 
-During sync, the block body withdrawal hash is computed from the withdrawals list in the block body. If Isthumus is
+During sync, the block body withdrawal hash is computed from the withdrawals list in the block body. If Isthmus is
 active at such a block's header, we expect that the computed withdrawal hash must match the hash of an empty list of
 withdrawals. The header `withdrawalsRoot` MPT hash can be any non-null value in this case. Verification is performed
-after a header is available so that the header's timestamp can be checked to see if Isthumus is active.
+after a header is available so that the header's timestamp can be checked to see if Isthmus is active.
 
 #### Backwards Compatibility Considerations
 
-Beginning at Shanghai and prior to Isthumus activation, the `withdrawalsRoot` field is set to the MPT root
+Beginning at Shanghai and prior to Isthmus activation, the `withdrawalsRoot` field is set to the MPT root
 of an empty withdrawals list. This is the same root as an empty storage root. The withdrawals are captured
-in the L2 state, however they are not reflected in the `withdrawalsRoot`. Hence, prior to Isthumus activation,
+in the L2 state, however they are not reflected in the `withdrawalsRoot`. Hence, prior to Isthmus activation,
 even if a `withdrawalsRoot` is present and a MPT root is present in the header, it should not be used.
 Any implementation that calculates output root should be careful not to use the header `withdrawalsRoot`.
 
-After Isthumus activation, if there was never any withdrawal contract storage, a MPT root of an empty list
+After Isthmus activation, if there was never any withdrawal contract storage, a MPT root of an empty list
 can be set as the `withdrawalsRoot`
 
 #### Forwards Compatibility Considerations
@@ -119,8 +124,6 @@ an outbound withdrawal for a long period of time, the node may not have access t
 [`L2ToL1MessagePasser`][l2-to-l1-mp]. In this case, the client would be unable to keep consensus. However, most modern
 clients are able to at the very least reconstruct the account storage root at a given block on the fly if it does not
 directly store this information.
-[l2-to-l1-mp]: ../../protocol/predeploys.md#L2ToL1MessagePasser
-[output-root]: ../../glossary.md#l2-output-root
 
 ##### Transaction Simulation
 
@@ -134,9 +137,9 @@ withdrawals list in the block body is encoded as an empty RLP list.
 
 ### Update to `ExecutableData`
 
-`ExecutableData` will contain an extra field for `withdrawalsRoot` after Isthumus hard fork.
+`ExecutableData` will contain an extra field for `withdrawalsRoot` after Isthmus hard fork.
 
 ### `engine_newPayloadV3` API
 
-Post Isthumus, `engine_newPayloadV3` will be used with the additional `ExecutionPayload` attribute. This attribute
-is omitted prior to Isthumus.
+Post Isthmus, `engine_newPayloadV3` will be used with the additional `ExecutionPayload` attribute. This attribute
+is omitted prior to Isthmus.

specs/protocol/proposals.md

@@ -19,6 +19,7 @@
 
 [g-rollup-node]: ../glossary.md#rollup-node
 [g-mpt]: ../glossary.md#merkle-patricia-trie
+[header-withdrawals-root]: ../protocol/isthmus/exec-engine.md#l2tol1messagepasser-storage-root-in-header
 
 ## Overview
 
@@ -113,8 +114,8 @@ where:
    thus reducing the verification cost of withdrawals on L1.
 
    After the Isthumus hard fork, the `withdrawal_storage_root` is present in the
-  [block header as `withdrawalsRoot`](../protocol/isthmus/exec-engine.md#l2tol1messagepasser-storage-root-in-header)
-   and can be used directly, instead of computing the storage root of the L2toL1MessagePasser contract.
+   [block header as `withdrawalsRoot`][header-withdrawals-root] and can be used directly, instead of computing
+  the storage root of the L2toL1MessagePasser contract.
 
 ## L2 Output Oracle Smart Contract
 

specs/protocol/rollup-node-p2p.md

@@ -269,7 +269,7 @@ Ecotone blocks are broadcast on `/optimism/<chainId>/2/blocks`.
 
 ### `blocksv4`
 
-Isthumus blocks are broadcast on `/optimism/<chainId>/3/blocks`.
+Isthmus blocks are broadcast on `/optimism/<chainId>/3/blocks`.
 
 ### Block encoding
 
@@ -417,7 +417,7 @@ Implementations may opt for a different limit, since this sync method is optiona
 - `1`: SSZ-encoded `ExecutionPayloadEnvelope` with Snappy framing compression,
   matching the `ExecutionPayloadEnvelope` SSZ definition of the L2 Ecotone version.
 - `2`: SSZ-encoded `ExecutionPayload` with Snappy framing compression,
-  matching the `ExecutionPayload` SSZ definition of the L2 Isthumus version.
+  matching the `ExecutionPayload` SSZ definition of the L2 Isthmus version.
 
 The request is by block-number, enabling parallel fetching of a chain across many peers.