lint: fix lint errors (#301)

rfc/004-abci++.md

@@ -42,6 +42,7 @@ This phase aims to allow applications to require their validators do more than j
 Example usecases of this include validator determined price oracles, validator guaranteed IBC connection attempts, and validator based threshold crypto.
 
 This adds an app-determined data field that every validator must include with their vote, and these will thus appear in the header.
+
 #### Rename {BeginBlock, [DeliverTx], EndBlock} to FinalizeBlock
 
 The prior phases gives the application more flexibility in their execution model for a block, and they obsolete the current methods for how the consensus engine relates the block data to the state machine. Thus we refactor the existing methods to better reflect what is happening in the new ABCI model.
@@ -185,7 +186,7 @@ We go through this phase by phase.
 
 ##### Prepare proposal IPC overhead
 
-This requires a round of IPC communication, where both directions are quite large. Namely the proposer communicating an entire block to the application. 
+This requires a round of IPC communication, where both directions are quite large. Namely the proposer communicating an entire block to the application.
 However, this can be mitigated by splitting up `PrepareProposal` into two distinct, async methods, one for the block IPC communication, and one for the Header IPC communication.
 
 Then for chains where the block data does not depend on the header data, the block data IPC communication can proceed in parallel to the prior block's voting phase. (As a node can know whether or not its the leader in the next round)

rfc/005-reverse-sync.md

@@ -40,6 +40,7 @@ other data retrieving protocols (i.e. fast sync and state sync), we
 call this method **ReverseSync**.
 
 We will define the mechanism in four sections:
+
 - Usage
 - Design
 - Verification
@@ -107,6 +108,7 @@ also doesn't need to rely on RPC.
 ### Verification
 
 ReverseSync is used to fetch the following data structures:
+
 - `Header`
 - `Commit`
 - `ValidatorSet`
@@ -115,21 +117,24 @@ Nodes will also need to be able to verify these. This can be achieved by first
 retrieving the header at the base height from the block store. From this trusted
 header, the node hashes each of the three data structures and checks that they are correct.
 
-1. The trusted header's last block ID matches the hash of the new header 
-```go
-header[height].LastBlockID == hash(header[height-1])
-```
+1. The trusted header's last block ID matches the hash of the new header
+
+   ```go
+   header[height].LastBlockID == hash(header[height-1])
+   ```
 
 2. The trusted header's last commit hash matches the hash of the new commit
-```go
-header[height].LastCommitHash == hash(commit[height-1])
-```
+
+	```go
+	header[height].LastCommitHash == hash(commit[height-1])
+	```
 
 3. Given that the node now trusts the new header, check that the header's validator set
-hash matches the hash of the validator set
-```go
-header[height-1].ValidatorsHash == hash(validatorSet[height-1])
-```
+   hash matches the hash of the validator set
+
+	```go
+	header[height-1].ValidatorsHash == hash(validatorSet[height-1])
+	```
 
 ### Termination
 
@@ -145,7 +150,7 @@ processes current block.
 
 This implies that we can't guarantee adequate history and thus the term
 "invariant" can't be used in the strictest sense. In the case that the first
-condition isn't met, the node will log an error and optimistically attempt 
+condition isn't met, the node will log an error and optimistically attempt
 to continue with either fast sync or consensus.
 
 ## Alternative Solutions
@@ -161,13 +166,13 @@ As it stands, if 2/3+ vote on evidence you can't verify, in the same manner if
 app hash), the node will halt.
 
 Another alternative is the method with which the relevant data is retrieved.
-Instead of introducing new messages to the P2P layer, RPC could have been used 
+Instead of introducing new messages to the P2P layer, RPC could have been used
 instead.
 
 The aforementioned data is already available via the following RPC endpoints:
 `/commit` for `Header`'s' and `/validators` for `ValidatorSet`'s'. It was
 decided predominantly due to the instability of the current RPC infrastructure
-that P2P be used instead. 
+that P2P be used instead.
 
 ## Status