docs: fix typos and grammar

docs/architecture/adr-002-qgb-valset.md

@@ -12,7 +12,7 @@ To accommodate the requirements of the [Quantum Gravity Bridge](https://github.c
 
 Add the `ValSet` and `ValSetConfirm` types of messages in order to track the state of the validator set.
 
-PS: The `ValsetConfirm` has been updated in `adr-005-qgb-reduce-state-usage`. Please take a look at it to know how we will be handling the confirms.
+PS: The `ValsetConfirm` has been updated in `adr-005-qgb-reduce-state-usage`. Please take a look at it to know how we will be handling the confirmations.
 
 ## Detailed Design
 

docs/architecture/adr-003-qgb-data-commitments.md

@@ -12,7 +12,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 at 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 at it to know how we will be handling the confirmations.
 
 ## Detailed Design
 

docs/architecture/adr-005-qgb-reduce-state-usage.md

@@ -36,7 +36,7 @@ This way, we will always have a fixed-sized state, issue defining this: [Prune t
 
 ### Separate P2P network
 
-This would mean gossiping about the confirms and attestations in a separate P2P network.
+This would mean gossiping about the confirmations and attestations in a separate P2P network.
 The pros of this approach are that it will be cheaper and wouldn't involve any state changes.
 However, slashing will be very difficult, especially for liveness, i.e. an orchestrator not signing an attestation and then slashing them after a certain period.
 

docs/architecture/adr-009-non-interactive-default-rules-for-reduced-padding.md

@@ -64,7 +64,7 @@ The commitment is still the same but we need to use the bottom subtree roots for
 
 Given a square size k, the biggest message that you can construct that is affected by the proposed non-interactive default rules has a size (k/2)². If you construct a message that is bigger than (k/2)² the `minSquareSize` will be k. If the minSquareSize is k in a square of size k then the current non-interactive default rules are equivalent to the proposed non-interactive default rules, because the message starts always at the beginning of a row. In other words, if you have k² shares in a message the worst constructible message is a quarter of that k²/4, because that is the size of the next smaller square.
 
-If you choose k²/4 as the worst constructible message it would still have O(sqrt(n)) subtree roots. This is because the size of the message is k²/4 with a width of k and a length of k/4. This means the number of rows the message fills approaches O(sqrt(n)). Therefore we need to find a message where the number of rows is log(n) of the size of the message.
+If you choose k²/4 as the worst constructible message it would still have O(sqrt(n)) subtree roots. This is because the size of the message is k²/4 with a width of k and a length of k/4. This means the number of rows the message fills approaches O(sqrt(n)). Therefore, we need to find a message where the number of rows is log(n) of the size of the message.
 
 With k being the square size and n being the number of shares and r being the number of rows, we want to find a message so that:
 k * r = n & log(n) = r => k = n/log(n)

docs/architecture/adr-011-optimistic-blob-size-independent-inclusion-proofs-and-pfb-fraud-proofs.md

@@ -78,7 +78,7 @@ Note: the blue nodes are additional nodes that are needed for the Merkle proofs.
 
 ![PFB Merkle Proof](./assets/adr011/pfd-merkle-proof.png)
 
-Let's assume a square size of k. The amount of blue nodes from the shares to ROW1 is O(log(k)). The amount of blue nodes from ROW1 to the `DataRoot` is also O(log(k). You will have to include the shares themselves in the proof.
+Let's assume a square size of k. The amount of blue nodes from the shares to ROW1 is O(log(k)). The amount of blue nodes from ROW1 to the `DataRoot` is also O(log(k)). You will have to include the shares themselves in the proof.
 Share size := 512 bytes
 NMT-Node size := 32 bytes + 2\*8 bytes = 48 bytes
 MT-Node size := 32 bytes