chore: fix typos in Readme (0xPolygonHermez#2980)

CONTRIBUTING.md

@@ -33,7 +33,7 @@ Note that non of this is a hard rule, but suggestions / guidelines. Although eve
 - Offer clarification, explain the decisions you made to reach a solution in question.
 - Try to respond to every comment.
 - If there is growing confusion or debate, ask yourself if the written word is still the best form of communication. Talk (virtually) face-to-face, then mutually consider posting a follow-up to summarize any offline discussion (useful for others who be following along, now or later).
-- If concensus is still not reached, involve someone else in the discussion. As a last resource the lead of the project could take the decision
+- If consensus is still not reached, involve someone else in the discussion. As a last resource the lead of the project could take the decision
 
 ## Links and credits
 

README.md

@@ -41,7 +41,7 @@ The diagram represents the main components of the software and how they interact
 - Synchronizer: Updates the `state` (virtual batches, verified batches, forced batches, ...) by fetching data from L1 through the `etherman`. If the node is not a `trusted sequencer` it also updates the state with the data fetched from the `rpc` of the `trusted sequencer`. It also detects and handles reorgs that can happen if the `trusted sequencer` sends different data in the rpc vs the sequences sent to L1 (trusted reorg aka L2 reorg). Also handles L1 reorgs (reorgs that happen on the L1 network)
 - State: Responsible for managing the state data (batches, blocks, transactions, ...) that is stored on the `state SB`. It also handles the integration with the `executor` and the `Merkletree` service
 - State DB: persistence layer for the state data (except the Merkletree that is handled by the `HashDB` service), it stores informationrelated to L1 (blocks, global exit root updates, ...) and L2 (batches, L2 blocks, transactions, ...)
-- Aggregator: consolidates batches by generating ZKPs (Zero Knowledge proofs). To do so it gathers the necessary data that the `prover` needs as input through the `state` and sends a request to it. Once the proof is generated it sends a request to send an L1 tx to verify the proof and move the state from virtual to verified to the `ethtxmanager`. Note that provers connect to the aggregator and not the other way arround. The aggregator can handle multiple connected provers at once and make them work concurrently in the generation of different proofs
+- Aggregator: consolidates batches by generating ZKPs (Zero Knowledge proofs). To do so it gathers the necessary data that the `prover` needs as input through the `state` and sends a request to it. Once the proof is generated it sends a request to send an L1 tx to verify the proof and move the state from virtual to verified to the `ethtxmanager`. Note that provers connect to the aggregator and not the other way around. The aggregator can handle multiple connected provers at once and make them work concurrently in the generation of different proofs
 - Prover/Executor/hashDB: service that generates ZK proofs. Note that this component is not implemented in this repository, and it's treated as a "black box" from the perspective of the node. The prover/executor has two implementations: [JS reference implementation](https://github.com/0xPolygonHermez/zkevm-proverjs) and [C production-ready implementation](https://github.com/0xPolygonHermez/zkevm-prover). Although it's the same software/binary, it implements three services:
   - Executor: Provides an EVM implementation that allows processing batches as well as getting metadata (state root, transaction receipts, logs, ...) of all the needed results.
   - Prover: Generates ZKPs for batches, batches aggregation, and final proofs.

docs/production-setup.md

@@ -85,7 +85,7 @@ There are some fundamental changes that can be done towards the basic setup, in
 
 ### DB
 
-In the basic setup, there are Postgres being instanciated as Docker containers. For better performance is recommended to:
+In the basic setup, there are Postgres being instantiated as Docker containers. For better performance is recommended to:
 
 - Run dedicated instances for Postgres. To achieve this you will need to:
   - Remove the Postgres services (`zkevm-pool-db` and `zkevm-state-db`) from the `docker-compose.yml`

tools/state/README.md

@@ -16,7 +16,7 @@ It have some flags to allow:
 it override state_db
 - `--fist_batch`: first batch to process (default: 1)
 - `--last_batch`: last batch to process (default: the highest batch on batch table)
-- `--l2_chain_id`:  Intead of asking to SMC you can set it 
+- `--l2_chain_id`:  Instead of asking to SMC you can set it 
 - `--dont_stop_on_error`: If a batch have an error the process doesn't stop
 - `--prefer_execution_state_root`: The oldStateRoot used to process a batch is usually is the stateRoot of the previous batch on database but, with this flag, you could use the calculated stateRoot from the execution result from previous batch instead
 
@@ -31,7 +31,7 @@ go run ./tools/state/. reprocess
 ```
 KEVM_NODE_MTCLIENT_URI="127.0.0.1:50061" ZKEVM_NODE_STATE_DB_HOST="127.0.0.1" ZKEVM_NODE_EXECUTOR_URI="127.0.0.1:50071" go run ./tools/state/. reprocess -cfg test/config/test.node.config.toml   -l2_chain_id 1440 --last_batch_number 5000
 ```
-- We are setting the `chain_id` direclty so we don't need the genesis data.
+- We are setting the `chain_id` directly so we don't need the genesis data.
 - All this examples redirect the log info to `/dev/null` for that reason if the command returns an error (`$? -ne 1`) relaunch without the redirection part (`2> /dev/null`) to see the full output
 
 ### Rebuild hashdb entries for first 5000 batches