fix(specs): Lint

specs/README.md

@@ -27,7 +27,7 @@ Our aim is to design a protocol specification that is:
 - **Fast:** When users send transactions, they get reliable confirmations with low-latency.
   For example when swapping on Uniswap you should see that your transaction succeed in less than 2
   seconds.
-- **Scalable:** It should be possible to handle an enormous number of transactions 
+- **Scalable:** It should be possible to handle an enormous number of transactions
   per second which will enable the system to charge low fees.
   V1.0 will enable Optimism to scale up to and even past the gas limit on L1.
   Later iterations should scale much further.
@@ -44,7 +44,7 @@ Our aim is to design a protocol specification that is:
   systems team consuming the spec is also key!
 - **Secure:** This is self-evident.
   User’s assets are at stake. Every component of the system must be incredibly secure.
-- **Decentralizable:** Optimism must be designed to avail itself of the security and 
+- **Decentralizable:** Optimism must be designed to avail itself of the security and
   censorship-resistant guarantees achieved by a decentralized system.
   Currently centralized components of the system should have a clear path towards decentralization.
   Already decentralized components of the system should be protected and preserved.

specs/introduction.md

@@ -94,7 +94,7 @@ At the heart of the network are users (us!). Users can:
 The sequencer is the primary block producer.
 There may be one sequencer **or** many using a consensus protocol.
 For 1.0.0, there is just one sequencer (currently operated under the oversight of the Optimism Foundation).
-In general, specifications may use "the sequencer" to be a stand-in term 
+In general, specifications may use "the sequencer" to be a stand-in term
 for the consensus protocol operated by multiple sequencers.
 
 The sequencer:

specs/predeploys.md

@@ -108,7 +108,7 @@ permissionlessly removed from the L2 supply by calling the `burn()` function.
 
 Address: `0x4200000000000000000000000000000000000002`
 
-The `DeployerWhitelist` is a predeploy that was used to provide additional safety 
+The `DeployerWhitelist` is a predeploy that was used to provide additional safety
 during the initial phases of Optimism.
 It previously defined the accounts that are allowed to deploy contracts to the network.
 

specs/proposals.md

@@ -26,8 +26,8 @@ proving any piece of data captured by the outputs.
 Proposers submit the output roots to L1 and can be contested with a fault proof,
 with a bond at stake if the proof is wrong.
 
-_Note_: Fault proofs on Optimism are not fully specified at this time. Although fault proof construction and verification 
-[is implemented in Cannon][cannon],
+_Note_: Fault proofs on Optimism are not fully specified at this time. Although fault proof 
+construction and verification [is implemented in Cannon][cannon],
 the fault proof game specification and integration of a output-root challenger into the [rollup-node][g-rollup-node]
 are part of later specification milestones.
 

specs/rollup-node.md

@@ -55,7 +55,7 @@ For a complete specification of the L2 block derivation, refer to the [L2 block
 
 ## L2 Output RPC method
 
-The Rollup node has its own RPC method, `optimism_outputAtBlock` which returns a 32 
+The Rollup node has its own RPC method, `optimism_outputAtBlock` which returns a 32
 byte hash corresponding to the [L2 output root](./proposals.md#l2-output-commitment-construction).
 
 [SSZ]: https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md