typo fixes

polytope-labs · Jan 19, 2024 · a1a8f34 · a1a8f34
1 parent 1236f32
commit a1a8f34
Show file tree

Hide file tree

Showing 3 changed files with 4 additions and 4 deletions.
diff --git a/docs/pages/protocol/consensus.mdx b/docs/pages/protocol/consensus.mdx
@@ -33,7 +33,7 @@ This transactions list $T_i$ can be seen as a list of database transactions $\{t
 
 ISMP's messaging abstraction is built on top of the `ConsensusClient`. We refer to it as a consensus client because that is precisely what it should be: a client that observes a blockchain's consensus messages in order to determine what is the canonical chain on the network. Armed with the knowledge of the canonical state of the chain, we are now able to verify the state proofs of the requests & responses that have been committed to the state trie.
 
-This document formally defines the `ConsensusClient`, which serves as an oracle for the canonical state of a state machine, and the corresponding `ConsensusMessage`, which is used to advance the state of the consensus client.
+This document formally defines the `ConsensusClient`, which serves as an oracle for the canonical state of a state machine, and the corresponding handlers which are used to modify the state of the consensus client.
 
 
 ## `ConsensusState`
@@ -42,7 +42,7 @@ We define the `ConsensusState` as the minimum data required by consensus clients
 
 ## `StateCommitment`
 
-We define the `StateCommitment` as a succinct, cryptographic commitment to the entire blockchain state at an arbitrary block height. This state commitment scheme used to derive this commitment must support partial reveals proofs that have a complexity of $O(\log_n)$ or better. This state commitment is also colloquially known as the *state_root*.
+We define the `StateCommitment` as a succinct, cryptographic commitment to the entire blockchain state at an arbitrary block height. The state scheme used to derive this commitment must support partial reveals proofs that have a complexity of $O(\log_n)$ or better. This state commitment is also colloquially known as the *state_root*.
 
 
 ## `ConsensusClient`

diff --git a/docs/pages/protocol/dispatcher.mdx b/docs/pages/protocol/dispatcher.mdx
@@ -1,6 +1,6 @@
 # ISMP Dispatcher
 
-The dispatcher is the public interface which `IsmpModule`s use to *dispatch* requests and responses. It is also responsible for committing the outgoing requests and responses to storage. It may do so in an overlay tree or the underlying state trie. This ensrues that state proofs maybe obtained for dispatched requests and responses. The dispatcher should emit relevant events after any dispatch operation. The interface for the Ismp Dispatcher is
+The dispatcher is the public interface which `IsmpModule`s use to *dispatch* requests and responses. It is also responsible for committing the outgoing requests and responses to storage. It may do so in an overlay tree or the underlying state trie. This ensures that state proofs maybe obtained for dispatched requests and responses. The dispatcher should also emit relevant events after any dispatch operation. The interface for the Ismp Dispatcher is
 
 ```rust
 /// Simplified POST request, intended to be used for sending outgoing requests

diff --git a/docs/pages/protocol/state-machine.mdx b/docs/pages/protocol/state-machine.mdx
@@ -64,4 +64,4 @@ The ISMP framework does not enforce where requests & responses should be persist
 
 ## `verify_state_proof`
 
-Given a `StateCommitmen`, an arbitrary set of keys and a state proof, this method should perform state proof verification and provide the verified values for provided storage keys. These keys may point to an empty leaf and as such should be represented with `Option::None`. This signals a non-membership proof for the provided keys which is used in request timeouts. State proof verification is also used in handling `Response::Get` in order to verify the storage values requested in the `Request::Get`
+Given a `StateCommitment`, an arbitrary set of keys and a state proof, this method should perform state proof verification and return the verified values for provided storage keys. These keys may point to an empty leaf and as such should be represented with `Option::None`. This signals a non-membership proof for the provided keys which is used in request timeouts. State proof verification is also used in handling `Response::Get` in order to verify the storage values requested in the `Request::Get`
Original file line number	Diff line number	Diff line change
Expand Up		@@ -64,4 +64,4 @@ The ISMP framework does not enforce where requests & responses should be persist

		## `verify_state_proof`

		Given a `StateCommitmen`, an arbitrary set of keys and a state proof, this method should perform state proof verification and provide the verified values for provided storage keys. These keys may point to an empty leaf and as such should be represented with `Option::None`. This signals a non-membership proof for the provided keys which is used in request timeouts. State proof verification is also used in handling `Response::Get` in order to verify the storage values requested in the `Request::Get`
		Given a `StateCommitment`, an arbitrary set of keys and a state proof, this method should perform state proof verification and return the verified values for provided storage keys. These keys may point to an empty leaf and as such should be represented with `Option::None`. This signals a non-membership proof for the provided keys which is used in request timeouts. State proof verification is also used in handling `Response::Get` in order to verify the storage values requested in the `Request::Get`