docs: fix typos (#3687)

* docs: fix typos * test: fix error because of typo * Fix misbehaviour test --------- Co-authored-by: Luca Joss <[email protected]> Co-authored-by: Luca Joss <[email protected]>
informalsystems · Nov 9, 2023 · 21e7fd2 · 21e7fd2
1 parent 0cd7b48
commit 21e7fd2
Show file tree

Hide file tree

Showing 9 changed files with 16 additions and 16 deletions.
diff --git a/ci/misbehaviour/misbehaviour_test.sh b/ci/misbehaviour/misbehaviour_test.sh
@@ -55,11 +55,11 @@ cat "$HERMES_LOG"
 info "--------------------------------------------------"
 echo ""
 
-if grep -q "Evidence succesfully submitted" "$HERMES_LOG"; then
+if grep -q "Evidence successfully submitted" "$HERMES_LOG"; then
+    info "Misbehaviour detected and submitted successfully!"
+else
     warn "Misbehaviour detection failed!"
     exit 1
-else
-    info "Misbehaviour detected and submitted successfully!"
 fi
 
 STOPPED_HEIGHT="$(curl -s http://localhost:$IBC_1_RPC_PORT/status | jq -r .result.sync_info.latest_block_height)"

diff --git a/docs/architecture/adr-002-ibc-relayer.md b/docs/architecture/adr-002-ibc-relayer.md
@@ -87,7 +87,7 @@ Initial version of the relayer assumes batching is supported by all chains. An o
 
 A correct relayer MUST:
 
-- **[R-config-start]** Read, parse, validate a configuration file upon start and configure itself for the specifed chains and paths
+- **[R-config-start]** Read, parse, validate a configuration file upon start and configure itself for the specified chains and paths
 - **[R-transport]** Have access to the networking protocols (e.g. TCP/IP, UDP/IP, or QUIC/IP) and physical transport, required to read the state of one blockchain/ machine and submit data to another
 - **[R-provider]** Maintain transport connections to at least one full node per chain
 - **[R-query]** Query IBC data on source and destination chains
@@ -308,7 +308,7 @@ Future versions may create multiple relay threads. One possibility is to create
 
 A relayer algorithm is described in [relayer algorithm described in IBC Specification](https://github.com/cosmos/ibc/tree/main/spec/relayer/ics-018-relayer-algorithms/README.md#L47) and [Go relayer implementation ](https://github.com/cosmos/relayer/blob/f3a302df9e6e0c28883f5480199d3190821bcc06/relayer/strategies.go#L49.).
 
-This section describes some of the details of the realy thread algorithm in the Rust implementation. Inputs are the IBC Events and the events of interest are described in Appendix A.
+This section describes some of the details of the really thread algorithm in the Rust implementation. Inputs are the IBC Events and the events of interest are described in Appendix A.
 
 At high level, for each event from a source chain, the relayer:
 - queries client, connection, channels and/or packet related state on source and destination chains,
@@ -318,7 +318,7 @@ At high level, for each event from a source chain, the relayer:
 
 #### Proofs
 The relayer must include proofs in some datagrams as required by the IBC handlers. There are two types of proofs:
-- proof of some local state on source chain (A). For example, a proof of correct connection state (`ProofInit`, `ProofTry`, `ProofAck`) is included in some of the connection handshake datagrams. The `ConnOpenTry` message includes the `ProofInit` that is obtained from chain A where the connection should be in `INIT` state and have certain local and counterpary identifiers. The message specific sections below go in more details.
+- proof of some local state on source chain (A). For example, a proof of correct connection state (`ProofInit`, `ProofTry`, `ProofAck`) is included in some of the connection handshake datagrams. The `ConnOpenTry` message includes the `ProofInit` that is obtained from chain A where the connection should be in `INIT` state and have certain local and counterparty identifiers. The message specific sections below go in more details.
 - proof that the chain A's IBC client `clB` is updated with a consensus state and height that have been stored on chain B.
 - these proofs are verified on chain B against the consensus state stored by the A client at `proof_height`.
 
@@ -350,7 +350,7 @@ One proposal is shown below and described in the rest of this section.
 ![IBC_client_heights](assets/IBC_client_heights.jpeg)
 
 The relayer creates a light client on B with `hi` and then updates it as required by processing different IBC events. Let `ha'` be the last consensus state for client on B.
-When some IBC event for X (connection, channel or packet) is received, it includes the height, let it be `hx-1` at which the event occured on A.
+When some IBC event for X (connection, channel or packet) is received, it includes the height, let it be `hx-1` at which the event occurred on A.
 According to the proposal here, the relayer should:
 - get the latest consensus state height of client on B, `ha`
 - let `h = max(hx, ha)`

diff --git a/docs/architecture/adr-003-handler-implementation.md b/docs/architecture/adr-003-handler-implementation.md
@@ -314,7 +314,7 @@ pub fn keep(
 > the actual requirements.
 
 Each submodule is responsible for dispatching the messages it is given to the appropriate
-message processing function and, if successful, pass the resulting data to the persistance
+message processing function and, if successful, pass the resulting data to the persistence
 function defined in the previous section.
 
 To this end, the submodule should define an enumeration of all messages, in order

diff --git a/docs/architecture/adr-007-error.md b/docs/architecture/adr-007-error.md
@@ -37,7 +37,7 @@ impl Kind {
 The design above is meant to separate between two concerns:
 
   - The metadata about an error, as captured in `Kind`.
-  - The trace of how the error occured, as captured in `anomaly::Context`.
+  - The trace of how the error occurred, as captured in `anomaly::Context`.
   - The type `Error` is defined to be `anomaly::Error<Kind>`, which is a newtype wrapper to `Box<anomaly::Context<Kind>>`.
 
 There are a few issues with the original design using `anomaly`:

diff --git a/docs/architecture/adr-008-ics20-implementation.md b/docs/architecture/adr-008-ics20-implementation.md
@@ -204,7 +204,7 @@ pub fn on_acknowledgement_packet<Ctx>(ctx: &Ctx, ack: ICS20Acknowledgement, data
     where Ctx: ICS20Context
 {
     match ack {
-        ICS20Acknowledgement::Sucess => Ok(()),
+        ICS20Acknowledgement::Success => Ok(()),
         _ => refund_packet_token(ctx, data)
     }
 }

diff --git a/docs/architecture/adr-011-light-client-crates-extraction.md b/docs/architecture/adr-011-light-client-crates-extraction.md
@@ -475,7 +475,7 @@ Proposed
 ## References
 
 * PRs for removing `Any*` enums:
-    * Remove all occurences of Any* enums from light clients
+    * Remove all occurrences of Any* enums from light clients
       ([PR #2332](https://github.com/informalsystems/hermes/pull/2332))
     * Remove Any* enums ([PR #2338](https://github.com/informalsystems/hermes/pull/2338))
 * Experimental PR for extracting `ibc-base` crate ([PR #2327](https://github.com/informalsystems/hermes/pull/2327))

diff --git a/docs/spec/connection-handshake/L1_2.md b/docs/spec/connection-handshake/L1_2.md
@@ -413,7 +413,7 @@ func ConnTryHandler(
 ```
 
 Preconditions:
-  - The input parameters should be valid; among others validation criterias, it is important that the module running this handler supports at least one of the versions supplied in the input list `remoteVersions` (see [validation](#Validation)).
+  - The input parameters should be valid; among others validation criteria, it is important that the module running this handler supports at least one of the versions supplied in the input list `remoteVersions` (see [validation](#Validation)).
   - The two proofs `remoteConnectionProof` and `remoteClientProof` should be correct. This is necessary in connection to properties [ICS3-Proto-2-ConnectionIntegrity] and [ICS3-Proto-3-StateConsistency]. Correctness of proofs means that they pass verification (`verifyProof` function).
 
 Postconditions:

diff --git a/docs/spec/connection-handshake/L2-tla/Environment.tla b/docs/spec/connection-handshake/L2-tla/Environment.tla
@@ -183,7 +183,7 @@ InitEnv ==
 
     This is part of the RelayNextEnv sub-action of the environment.
     This performs a basic relaying step, that is, passing a message from the
-    output buffer of one of the chains (paramter 'from') into the input buffer
+    output buffer of one of the chains (parameter 'from') into the input buffer
     of another chain (parameter 'to').
 
  *)
@@ -199,7 +199,7 @@ RelayMessage(from, to) ==
     This step may change (non-deterministically) either of the store of chain A
     or B, by advancing the height of that chain. This can only enable if the
     respective chain has ample steps left, i.e., the chain height is not within 4 steps
-    of the maximum height. This precondition disallow continuos advancing of chain heights,
+    of the maximum height. This precondition disallow continuous advancing of chain heights,
     and therefore allows chains to take meaningful steps (executing the ICS3 protocol to
     completion).
 
@@ -299,7 +299,7 @@ ICS3ReachedOpenConnection ==
 (* Enables when both chains are stuck, i.e., unable to progress while
     their connection is not opened.
 
-    State predicate signaling that the protocol terminated unsucessfully.
+    State predicate signaling that the protocol terminated unsuccessfully.
 
  *)
 ICS3ImpossibleToAdvance ==

diff --git a/docs/spec/connection-handshake/L2-tla/README.md b/docs/spec/connection-handshake/L2-tla/README.md
@@ -31,7 +31,7 @@ ASSUME VersionPickMode \in
 ```
 
 Typical values could be: `MaxHeight = 5` and `MaxBufLen = 2`.
-The `Concurrency` flag enables/disables some non-determinsm of the environment,
+The `Concurrency` flag enables/disables some non-determinism of the environment,
 specifically:
 
 - if TRUE, then the environment can non-deterministically update the light client of a chain.