diff --git a/ci/misbehaviour/misbehaviour_test.sh b/ci/misbehaviour/misbehaviour_test.sh index 32d91a23c3..88e0f923f4 100755 --- 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 index fe9e4baae9..6ca29cb00a 100644 --- 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 index 7062c717bf..62693d1c3f 100644 --- 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 index 0d1a18f34f..f56dbddb65 100644 --- 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`, which is a newtype wrapper to `Box>`. 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 index 3839a2315a..afbdaa1531 100644 --- 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, 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 index f008f9e713..79465da8fa 100644 --- 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 index 68bd28aa8f..66a7eaa4eb 100644 --- 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 index ed05bea075..c90176530b 100644 --- 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 index 0c828bfe7f..d0572c3d38 100644 --- 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.