README.md, docs: fix typos in documentation

README.md

@@ -19,9 +19,9 @@ for validating Ethereum client implementations.
 - go-ethereum:
   - Genesis chain config couldn't handle present but empty settings: [#2790](https://github.com/ethereum/go-ethereum/pull/2790)
   - Data race between remote block import and local block mining: [#2793](https://github.com/ethereum/go-ethereum/pull/2793)
-  - Downloader didn't penalize incompatible forks hashly enough: [#2801](https://github.com/ethereum/go-ethereum/pull/2801)
+  - Downloader didn't penalize incompatible forks harshly enough: [#2801](https://github.com/ethereum/go-ethereum/pull/2801)
 - Nethermind:
-  - Bug in p2p whith bonding nodes algorithm found by Hive: [#1894](https://github.com/NethermindEth/nethermind/pull/1894)
+  - Bug in p2p with bonding nodes algorithm found by Hive: [#1894](https://github.com/NethermindEth/nethermind/pull/1894)
   - Difference in return value for 'r' parameter in getTransactionByHash: [#2372](https://github.com/NethermindEth/nethermind/issues/2372)
   - CREATE/CREATE2 behavior when account already has max nonce [#3698](https://github.com/NethermindEth/nethermind/pull/3698)
   - Blake2 performance issue with non-vectorized code [#3837](https://github.com/NethermindEth/nethermind/pull/3837)
@@ -36,7 +36,7 @@ We follow the [Collective Code Construction Contract (C4)][c4], code contributio
 as expanded and explained in [The ZeroMQ Process][zmq-process]. The core idea being that
 any patch that successfully solves an issue (bug/feature) and doesn't break any existing
 code/contracts must be optimistically merged by maintainers. Followup patches may be used
-to for additional polishes – and patches may even be outright reverted if they turn out to
+for additional polishes – and patches may even be outright reverted if they turn out to
 have a negative impact – but no change must be rejected based on personal values.
 
 ### License

docs/clients.md

@@ -5,7 +5,7 @@
 This page explains how client containers work in Hive.
 
 Clients are docker images which can be instantiated by a simulation. A client definition
-consist of a Dockerfile and associated resources. Client definitions live in
+consists of a Dockerfile and associated resources. Client definitions live in
 subdirectories of `clients/` in the hive repository.
 
 When hive runs a simulation, it first builds all client docker images using their
@@ -108,7 +108,7 @@ URL of the running instance.
 ### Environment
 
 Clients must support the following environment variables. The client's entry point script
-may map these to command line flags or use them generate a config file, for example.
+may map these to command line flags or use them to generate a config file, for example.
 
 | Variable                   | Value         |                                                |
 |----------------------------|---------------|------------------------------------------------|

docs/simulators.md

@@ -343,7 +343,7 @@ Response:
 
     {"id": "<container-id>", "ip": "172.1.2.4"}
 
-#### Geting client information
+#### Getting client information
 
     GET /testsuite/{suite}/test/{test}/node/{container}