Fix typos and minor comment cleanup in ADR documentation (#24974)

Co-authored-by: Alex | Interchain Labs <alex@interchainlabs.io>

docs/architecture/adr-012-state-accessors.md

@@ -67,7 +67,7 @@ func (Value) Set(ctx Context, o interface{}) {}
 // Check if a raw value exists
 func (Value) Exists(ctx Context) bool {}
 
-// Delete a raw value value
+// Delete a raw value 
 func (Value) Delete(ctx Context) {}
 ```
 

docs/architecture/adr-014-proportional-slashing.md

@@ -49,7 +49,7 @@ Griefing, the act of intentionally getting oneself slashed in order to make anot
 
 ### Implementation
 
-In the slashing module, we will add two queues that will track all of the recent slash events.  For double sign faults, we will define "recent slashes" as ones that have occurred within the last `unbonding period`.  For liveness faults, we will define "recent slashes" as ones that have occurred withing the last `jail period`.
+In the slashing module, we will add two queues that will track all of the recent slash events.  For double sign faults, we will define "recent slashes" as ones that have occurred within the last `unbonding period`.  For liveness faults, we will define "recent slashes" as ones that have occurred within the last `jail period`.
 
 ```go
 type SlashEvent struct {

docs/architecture/adr-018-extendable-voting-period.md

@@ -27,7 +27,7 @@ There is a new `Msg` type called `MsgExtendVotingPeriod`, which can be sent by a
 
 So for example, if the `MaxVotingPeriodExtension` is set to 100 Days, then anyone with 1% of voting power can extend the voting power by 1 day.  If 33% of voting power has sent the message, the voting period will be extended by 33 days.  Thus, if absolutely everyone chooses to extend the voting period, the absolute maximum voting period will be `MinVotingPeriod + MaxVotingPeriodExtension`.
 
-This system acts as a sort of distributed coordination, where individual stakers choosing to extend or not, allows the system the guage the conentiousness/complexity of the proposal.  It is extremely unlikely that many stakers will choose to extend at the exact same time, it allows stakers to view how long others have already extended thus far, to decide whether or not to extend further.
+This system acts as a sort of distributed coordination, where individual stakers choosing to extend or not, allows the system the gauge the contentiousness/complexity of the proposal.  It is extremely unlikely that many stakers will choose to extend at the exact same time, it allows stakers to view how long others have already extended thus far, to decide whether or not to extend further.
 
 ### Dealing with Unbonding/Redelegation
 

docs/architecture/adr-021-protobuf-query-encoding.md

@@ -15,7 +15,7 @@ This ADR is a continuation of the motivation, design, and context established in
 [ADR 020](./adr-020-protobuf-transaction-encoding.md), namely, we aim to design the
 Protocol Buffer migration path for the client-side of the Cosmos SDK.
 
-This ADR continues from [ADD 020](./adr-020-protobuf-transaction-encoding.md)
+This ADR continues from [ADR 020](./adr-020-protobuf-transaction-encoding.md)
 to specify the encoding of queries.
 
 ## Decision
@@ -176,7 +176,7 @@ service Query {
 }
 ```
 
-grpc-gateway will work direcly against the GRPC proxy described above which will
+grpc-gateway will work directly against the GRPC proxy described above which will
 translate requests to ABCI queries under the hood. grpc-gateway can also
 generate Swagger definitions automatically.
 

docs/architecture/adr-023-protobuf-naming.md

@@ -70,7 +70,7 @@ Further guidelines to be described below.
 Names should be descriptive enough to convey their meaning and distinguish
 them from other names.
 
-Given that we are using fully-qualifed names within
+Given that we are using fully-qualified names within
 `google.protobuf.Any` as well as within gRPC query routes, we should aim to
 keep names concise, without going overboard. The general rule of thumb should
 be if a shorter name would convey more or else the same thing, pick the shorter

docs/architecture/adr-028-public-key-addresses.md

@@ -322,14 +322,14 @@ Module addresses: Should module addresses have different size to differentiate i
 * we will need to set a pre-image prefix for module addresse to keept them in 32-byte space: `hash(hash('module') + module_key)`
 * Aaron observation: we already need to deal with variable length (to not break secp256k1 keys).
 
-Discssion about arithmetic hash function for ZKP
+Discussion about arithmetic hash function for ZKP
 
 * Posseidon / Rescue
 * Problem: much bigger risk because we don’t know much techniques and history of crypto-analysis of arithmetic constructions. It’s still a new ground and area of active research.
 
 Post quantum signature size
 
-* Alan suggestion: Falcon: speed / size ration - very good.
+* Alan suggestion: Falcon: speed / size ratio - very good.
 * Aaron - should we think about it?
   Alan: based on early extrapolation this thing will get able to break EC cryptography in 2050 . But that’s a lot of uncertainty. But there is magic happening with recurions / linking / simulation and that can speedup the progress.