Spell Check: Fix typos (#8480)

Spell Check: 

Concensus --> Consensus
prodiced --> produced
configuraion --> configuration
cabable --> capable
structue --> structure
eample --> example
nework --> network
configration --> configuration
regestering --> registering 
registratio --> registration
excuted --> executed
Simlarly --> Similarly
dictactes --> dictates
respresented --> represented
lengthes --> lengths

.github/ISSUE_TEMPLATE/bug.md

@@ -16,9 +16,9 @@ Commit hash:
 
 Erigon Command (with flags/config):
 
-Concensus Layer:
+Consensus Layer:
 
-Concensus Layer Command (with flags/config):
+Consensus Layer Command (with flags/config):
 
 Chain/Network: 
 

README.md

@@ -141,7 +141,7 @@ int value specifying the highest output log level:
   LvlTrace = 5
 ```
 
-To set an output dir for logs to be collected on disk, please set `--log.dir.path` If you want to change the filename prodiced from `erigon` you should also set the `--log.dir.prefix` flag to an alternate name. The flag `--log.dir.verbosity` is
+To set an output dir for logs to be collected on disk, please set `--log.dir.path` If you want to change the filename produced from `erigon` you should also set the `--log.dir.prefix` flag to an alternate name. The flag `--log.dir.verbosity` is
 also available to control the verbosity of this logging, with the same int value as above, or the string value e.g. '
 debug' or 'info'. Default verbosity is 'debug' (4), for disk logging.
 

cmd/devnet/README.md

@@ -9,7 +9,7 @@ The devnet code performs 3 main functions:
 * It allows for the specification of a series of scenarios which will be run against the nodes on that internal network
 * It can optionally run a `support` connection which allows the nodes on the network to be connected to the Erigon diagnostic system
 
-The specification of both nodes and scenarios for the devenet is done by specifying configuraion objects.  These objects are currently build in code using go `structs` but are cabable of being read as configuration.
+The specification of both nodes and scenarios for the devenet is done by specifying configuration objects.  These objects are currently build in code using go `structs` but are capable of being read as configuration.
 
 ## Devnet runtime start-up
 
@@ -28,7 +28,7 @@ The devnet runs as a single `go` process which can be started with the following
 
 ## Network Configuration
 
-Networks configurations are currently specified in code in `main.go` in the `selectNetwork` function.  This contains a series of `structs` with the following structue, for eample:
+Networks configurations are currently specified in code in `main.go` in the `selectNetwork` function.  This contains a series of `structs` with the following structure, for example:
 
 ```go
 		return &devnet.Network{
@@ -55,11 +55,11 @@ Networks configurations are currently specified in code in `main.go` in the `sel
 		}, nil	
 ```
 
-Base IP's and addresses are iterated for each node in the network - to ensure that when the network starts there are no port clashes as the entire nework operates in a single process, hence shares a common host.  Individual nodes will be configured with a default set of command line arguments dependent on type. To see the default arguments per node look at the `args\node.go` file where these are specified as tags on the struct members.
+Base IP's and addresses are iterated for each node in the network - to ensure that when the network starts there are no port clashes as the entire network operates in a single process, hence shares a common host.  Individual nodes will be configured with a default set of command line arguments dependent on type. To see the default arguments per node look at the `args\node.go` file where these are specified as tags on the struct members.
 
 ## Scenario Configuration
 
-Scenarios are similarly specified in code in `main.go` in the `action` function.  This is the initial configration:
+Scenarios are similarly specified in code in `main.go` in the `action` function.  This is the initial configuration:
 
 ```go
     scenarios.Scenario{
@@ -74,9 +74,9 @@ Scenarios are similarly specified in code in `main.go` in the `action` function.
     })
 ```
 
-Scenarios are created a groups of steps which are created by regestering a `step` handler too see an example of this take a look at the `commands\ping.go` file which adds a ping rpc method (see `PingErigonRpc` above).
+Scenarios are created a groups of steps which are created by registering a `step` handler too see an example of this take a look at the `commands\ping.go` file which adds a ping rpc method (see `PingErigonRpc` above).
 
-This illustrates the registratio process.  The `init` function in the file registers the method with the `scenarios` package - which uses the function name as the default step name.  Others can be added with additional string arguments fo the `StepHandler` call where they will treated as regular expressions to be matched when processing scenario steps.
+This illustrates the registration process.  The `init` function in the file registers the method with the `scenarios` package - which uses the function name as the default step name.  Others can be added with additional string arguments fo the `StepHandler` call where they will treated as regular expressions to be matched when processing scenario steps.
 
 ```go
 func init() {

cmd/evm/testdata/3/readme.md

@@ -1,2 +1,2 @@
-These files examplify a transition where a transaction (excuted on block 5) requests
+These files examplify a transition where a transaction (executed on block 5) requests
 the blockhash for block `1`. 

cmd/evm/testdata/4/readme.md

@@ -1,3 +1,3 @@
-These files examplify a transition where a transaction (excuted on block 5) requests
+These files examplify a transition where a transaction (executed on block 5) requests
 the blockhash for block `4`, but where the hash for that block is missing. 
 It's expected that executing these should cause `exit` with errorcode `4`.

cmd/evm/testdata/8/readme.md

@@ -33,7 +33,7 @@ dir=./testdata/8 && ./evm t8n --state.fork=Berlin --input.alloc=$dir/alloc.json
 
 ```
 
-Simlarly, we can provide the input transactions via `stdin` instead of as file: 
+Similarly, we can provide the input transactions via `stdin` instead of as file: 
 
 ```
 dir=./testdata/8 \

docs/examples/single-process.md

@@ -27,7 +27,7 @@ This runs Erigon with RPCDaemon, TxPool etc. all in one single process. This is
 
 ## Flags of Interest
 
-- `--chain` dictactes the chain (goerli/mainnet etc.) - https://chainlist.org/ is a helpful resource
+- `--chain` dictates 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 consensus layer (PoS) uses to talk to Erigon

docs/programmers_guide/guide.md

@@ -450,7 +450,7 @@ also pushes the hash of the byte code onto the hash stack.
 the node stack.
 
 `ACCOUNTLEAF` opcode is similar to `LEAF`. It consumes the next item from the key tape. The rest of the semantics
-depends on the value of the `field-set`. Field set can be respresented by a bitmask. In that case, bit 0 would
+depends on the value of the `field-set`. Field set can be represented by a bitmask. In that case, bit 0 would
 correspond to field 0, bit 1 (number 2) - to field 1, bit 2 (number 4) - to field 2. Currently, field 0 means account
 nonce, field 1 means account balance, field 2 means contract storage, field 3 means contract code.
 

erigon-lib/kv/temporal/historyv2/readme.md

@@ -50,7 +50,7 @@ AccountChangeSet is serialized in the following manner in order to facilitate bi
 ### Keys
 The number of keys N (uint32, 4 bytes)
 Contiguous array of keys (N*32 bytes)
-### Values lengthes
+### Values lengths
  Contiguous array of accumulating value indexes:
 len(val0), len(val0)+len(val1), ..., len(val0)+len(val1)+...+len(val_{N-1})
 (4*N bytes since the lengths are treated as uint32).
@@ -61,5 +61,5 @@ Value | Type | Comment
 ------------ | ------------- | -------------
 num of keys | uint32 |
 address hashes | [num of keys][32]byte | [num of keys]common.Hash
-values lengthes | [num of keys]uint32
+values lengths | [num of keys]uint32
 values | [num of keys][]byte