Merge pull request #143 from ethereum-optimism/refcell/fix/chain-id

fix: Inconsistent Chain ID Format

specs/interop/dependency_set.md

@@ -26,7 +26,7 @@ of executing messages.
 
 The dependency set is configured on a per chain basis.
 
-The chainid of the local chain MUST be considered as part of its own dependency set.
+The chain id of the local chain MUST be considered as part of its own dependency set.
 
 While the dependency set explicitly defines the set of chains that are depended on for incoming messages,
 the full set of transitive dependencies must be known to allow for the progression of [safety](#safety).

specs/interop/messaging.md

@@ -75,7 +75,7 @@ struct Identifier {
 | `blocknumber` | `uint256` | Block number in which the log was emitted                                       |
 | `logIndex`    | `uint256` | The index of the log in the array of all logs emitted in the block              |
 | `timestamp`   | `uint256` | The timestamp that the log was emitted. Used to enforce the timestamp invariant |
-| `chainid`     | `uint256` | The chainid of the chain that emitted the log                                   |
+| `chainid`     | `uint256` | The chain id of the chain that emitted the log                                  |
 
 The [`Identifier`] includes the set of information to uniquely identify a log. When using an absolute
 log index within a particular block, it makes ahead of time coordination more complex. Ideally there

specs/interop/predeploys.md

@@ -133,7 +133,7 @@ as well as domain binding, ie the executing transaction can only be valid on a s
 
 - Only callable by the `CrossL2Inbox`
 - The `Identifier.origin` MUST be `address(L2ToL2CrossDomainMessenger)`
-- The `_destination` chainid MUST be equal to the local chainid
+- The `_destination` chain id MUST be equal to the local chain id
 - The `CrossL2Inbox` cannot call itself
 
 ### Message Versioning

specs/protocol/span-batches.md

@@ -262,7 +262,7 @@ The assumption makes upper inequality to hold. Therefore, we decided to manage `
 - Transactions
   - Deposit transactions can be derived from its L1 origin, identical with V0 batch.
   - User transactions can be derived by following way:
-    - Recover `V` value of TX signature from `y_parity_bits` and L2 chainId, as described in optimization strategies.
+    - Recover `V` value of TX signature from `y_parity_bits` and L2 chain id, as described in optimization strategies.
     - When parsing `tx_tos`, `contract_creation_bits` is used to determine if the TX has `to` value or not.
 
 ## Integration