Fix: typos (#6613)

Fix: typos

docs/evm_semantics.md

@@ -14,9 +14,9 @@ transition function:
 `STATE_end = STATE_TR_FUNC(STATE_init, env, tx)`
 
 But this is not the only way to describe state transitions.
-And it is not always the most convinient way. In our approach, we will instead describe state transitions as a set of boolean expressions.
+And it is not always the most convenient way. In our approach, we will instead describe state transitions as a set of boolean expressions.
 They are boolean in the sense that they can be evaluated to either `true` or `false`, but they can rely on variety of types.
-These expressions will only tell us whether certain combination of the initial state, environment, transaction object, and the end state,
+These expressions will only tell us whether certain combinations of the initial state, environment, transaction object, and the end state,
 are all part of a valid state transition. However, they do not have a goal of helping us to determine (compute) the end state from
 the initial state, environment, and the transaction object. So they look more like this:
 
@@ -29,7 +29,7 @@ evaluation:
 
 From our experience with EVM and Ethereum, we know that each transaction can normally be decomposed into series of intermediate transitions.
 These intermediate transitions could be various internal accounting steps of Ethereum (like purchasing gas for Ether, or gas refunds), or
-steps of the EVM interpreter. In other words, the decomposion could look omething like this:
+steps of the EVM interpreter. In other words, the decomposition could look something like this:
 
 `EXPRESSION_1(STATE_init, env, tx, STATE_1, ORACLE_input1) == E1`
 
@@ -48,7 +48,7 @@ How do these expressions re-compose back into the `EXPRESSION`?. First of all, w
 Obviously, oracle input of the `EXPRESSION` could simply be a collection of all individual oracle inputs.
 
 Next observation we make is that the intermediate transitions are usually quite "local", which means that if we compare
-the initial state and the end state of each of those transitions, the difference between can be described succintly. This
+the initial state and the end state of each of those transitions, the difference between can be described succinctly. This
 can be understood as the length of the description having a pre-determined upper bound. Since there is no upper bound on
 the size of the state, we need a way of specifying part of the state the state transition modifies. At this point, we
 choose to represent the state as an array of accounts. Here, we use "array" in the context of theory of arrays. In this

docs/examples/single-process.md

@@ -29,4 +29,4 @@ This runs Erigon with RPCDaemon, TxPool etc. all in one single process. This is
 - `--chain` dictactes the chain (goerli/mainnet etc.) - https://chainlist.org/ is a helpful resource
 - `--log.dir.path` dictates where logs will be output - useful for sending reports to the Erigon team when issues occur
 - `--http.api` defines the set of APIs which are enabled, the above example is a pretty comprehensive list - what these do is beyond the scope of this example
-- `--authrpc.port` is the port which the concensus layer (PoS) uses to talk to Erigon
+- `--authrpc.port` is the port which the consensus layer (PoS) uses to talk to Erigon

docs/programmers_guide/witness_formal_spec.md

@@ -1,6 +1,6 @@
 # Block Witness Formal Specification
 
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
 
 ## Data Types
 
@@ -58,7 +58,7 @@ type Witness = (Node|Instruction...)
 ```
 
 
-## Execution Enviroment
+## Execution Environment
 
 The witness execution environment MUST contain the following 2 elements:
 
@@ -74,7 +74,7 @@ The witness execution environment MUST contain the following 2 elements:
 Initially, the Witness MUST BE an array of `Instruction`s.
 
 Then, as substitution rules are applied to the witness, some elements of the
-array are replaces with `Node`s.
+array are replaced with `Node`s.
 
 The execution continues until there are no substitution rules left to execute.
 
@@ -125,7 +125,7 @@ witness.
 ### Building a single trie from the witness
 
 If we are building a single trie from the witness, then the only SUCCESS
-executon is when the following are true:
+execution is when the following are true:
 
 - The execution state MUST match the End Criteria
 - There MUST be only one item left in the witness
@@ -340,7 +340,7 @@ CODE(raw_code) |=> CodeNode{raw_code}
 ### `ACCOUNT_LEAF key nonce balance has_code has_storage`
 
 Replaces the instruction and, optionally, up to 2 nodes to the left of the
-instructon with a single `AccountNode` wrapped with a `LeafNode`.
+instruction with a single `AccountNode` wrapped with a `LeafNode`.
 
 **Substitution rules**