chore: consistent ADR titles (#772)

docs/architecture/ADR-002-QGB-ValSet.md

@@ -8,7 +8,7 @@ To accommodate the requirements of the [Quantum Gravity Bridge](https://github.c
 
 Add the `ValSet` and `ValSetConfirm` type of messages in order to track the state of the validator set.
 
-PS: The `ValsetConfirm` have been updated in `ADR-005-QGB_reduce_state_usage`. Please take a look on it to know how we will be handling the confirms.
+PS: The `ValsetConfirm` have been updated in `ADR-005-QGB-reduce-state-usage`. Please take a look on it to know how we will be handling the confirms.
 
 ## Detailed Design
 
@@ -137,7 +137,7 @@ The significance of power difference is calculated using a pre-defined constant.
 ```go
 // SignificantPowerDifferenceThreshold the threshold of change in the validator set power
 // that would need the creation of a new valset request.
-const SignificantPowerDifferenceThreshold = 0.05 
+const SignificantPowerDifferenceThreshold = 0.05
 ```
 
 For more information on the normalization of power, check [here](https://github.com/celestiaorg/celestia-app/blob/df46d122da5f1fab1bd99bfb2bfcf9002f5bc154/x/qgb/types/validator.go#L101

docs/architecture/ADR-003-QGB-DataCommitment.md → docs/architecture/adr-003-QGB-data-commitments.md

@@ -8,7 +8,7 @@ To accommodate the requirements of the [Quantum Gravity Bridge](https://github.c
 
 Add the `DataCommitmentConfirm` type of messages in order to attest that a set of blocks has been finalized.
 
-PS: The `ValsetConfirm` have been updated in `ADR-005-QGB_reduce_state_usage`. Please take a look on it to know how we will be handling the confirms.
+PS: The `ValsetConfirm` have been updated in `ADR-005-QGB-reduce-state-usage`. Please take a look on it to know how we will be handling the confirms.
 
 ## Detailed Design
 
@@ -123,10 +123,10 @@ Then, we continue to broadcast an event containing the message:
 ```go
 ctx.EventManager().EmitEvent(
     sdk.NewEvent(
-        sdk.EventTypeMessage, 
+        sdk.EventTypeMessage,
         sdk.NewAttribute(sdk.AttributeKeyModule, msg.Type()),
-        sdk.NewAttribute(types.AttributeKeyDataCommitmentConfirmKey, msg.String()), 
-    ), 
+        sdk.NewAttribute(types.AttributeKeyDataCommitmentConfirmKey, msg.String()),
+    ),
 )
 ```
 

docs/architecture/ADR-004-QGB_relayer_security.md → docs/architecture/adr-004-QGB-relayer-security.md

@@ -1,4 +1,4 @@
-# ADR 4: QGB Relayer security design
+# ADR 004: QGB Relayer Security
 
 ## Changelog
 
@@ -7,21 +7,21 @@
 ## Context
 
 The current QGB design requires relayers to relay everything in a perfect synchronous order, but the contracts do not.
-In fact, the QGB smart contract is designed to update the data commitments as follows:  
+In fact, the QGB smart contract is designed to update the data commitments as follows:
 
-- Receive a data commitment  
-- Check that the block height (nonce) is higher than the previously committed root  
-- Check if the data commitment is signed using the current valset _(this is the problematic check)_  
+- Receive a data commitment
+- Check that the block height (nonce) is higher than the previously committed root
+- Check if the data commitment is signed using the current valset _(this is the problematic check)_
 - Then, other checks + commit
 
 So, if a relayer is up to date, it will submit data commitment and will pass the above checks.
 
-Now, if the relayer is missing some data commitments or valset updates, then it will start catching up the following way:  
+Now, if the relayer is missing some data commitments or valset updates, then it will start catching up the following way:
 
-- Relay valset  
-- Keep relaying all data commitments that were signed using that valset  
-- If a new valset is found, check that: up to the block where the valset was changed, all the data commitments that happened during that period are relayed  
-- Relay the next valset  
+- Relay valset
+- Keep relaying all data commitments that were signed using that valset
+- If a new valset is found, check that: up to the block where the valset was changed, all the data commitments that happened during that period are relayed
+- Relay the next valset
 - And, so on.
 
 The problem with this approach is that there is constant risk for any relayer to mess the ordering of the attestations submission, ie relaying the next valset before relaying all the data commitments that were signed using the previous valset, and end up with signatures holes.
@@ -63,10 +63,10 @@ This approach consists of switching to a synchronous QGB design utilizing univer
 Update the QGB contract to store the valset hashes + their nonces:
 
 - Cons:
-  - Would make the contract more complex  
+  - Would make the contract more complex
 - Pros:
-  - Would make the relayer parallelizable (can submit data commitments and valsets in any order as long as the valset is committed)  
-  - would allow the QGB to catchup correctly even in the existence of a malicious relayer  
+  - Would make the relayer parallelizable (can submit data commitments and valsets in any order as long as the valset is committed)
+  - would allow the QGB to catchup correctly even in the existence of a malicious relayer
 
 ### A request oriented design
 

docs/architecture/ADR-005-QGB_reduce_state_usage.md → docs/architecture/adr-005-QGB-reduce-state-usage.md

@@ -1,4 +1,4 @@
-# ADR 5: Reduce QGB state usage
+# ADR 005: QGB Reduce State Usage
 
 ## Context