Fix errors in documentation files

CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 This document addresses how we should create PRs, give and receive reviews. The motivation is to have better code, reduce the time from creation to merge while sharing knowledge and insights that help everyone becoming better developers.
 
-Note that non of this is a hard rule, but suggestions / guidelines. Although everyone is encouraged to stick to this points as much as possible. Use your common sense if some of this do not apply well on a particular PR
+Note that none of this is a hard rule, but suggestions / guidelines. Although everyone is encouraged to stick to this points as much as possible. Use your common sense if some of this do not apply well on a particular PR
 
 ## How to create a good PR
 
@@ -40,4 +40,4 @@ Note that non of this is a hard rule, but suggestions / guidelines. Although eve
 This guide is based on the following content:
 
 - https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
-- https://github.blog/2015-01-21-how-to-write-the-perfect-pull-request/
+- https://github.blog/2015-01-21-how-to-write-the-perfect-pull-request/

README.md

@@ -40,7 +40,7 @@ The diagram represents the main components of the software and how they interact
 - Etherman: abstraction that implements the needed methods to interact with the Ethereum network and the relevant smart contracts.
 - 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, ...)
+- State DB: persistence layer for the state data (except the Merkletree that is handled by the `HashDB` service), it stores information related 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 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.

docs/ci/actions.md

@@ -45,7 +45,7 @@ Runs e2e tests divided in several groups executed in parallel, read more about
 ### When is executed
 
 PR opened and pushing changes to PRs. There are two variants, `trusted` and
-`from-fork`, depending on the procedence of the PR, more about it in the
+`from-fork`, depending on the provenance of the PR, more about it in the
 [ok-to-test document].
 
 ## test-full-non-e2e

docs/ci/ok-to-test.md

@@ -20,7 +20,7 @@ don't require secrets and trusted actions are executed.
 executed, and the from-fork actions are executed after a user with write access
 comments in the PR `/ok-to-test sha=<commit sha>` with the sha of the commit over
 which the actions should run. Before adding this comment the user should have
-reviewed the code and verified that it won't suppose a security treat (for
+reviewed the code and verified that it won't suppose a security threat (for
 instance, the reviewer should verify that the PR is not adding new actions, or is
 not trying to disclose the existing secrets).
 

docs/ci/opsman.md

@@ -1,7 +1,7 @@
 # Test operations package
 
 We use the functionality provided by the [test operations package] in order to
-manage components used during tests, specially e2e.
+manage components used during tests, especially e2e.
 
 The main functionality used currently in the tests is related to managing
 containers, the package exposes the function `StartComponent` which takes a

docs/configuration.md

@@ -8,14 +8,14 @@ To configure a node you need 3 files:
 ### Node Config
 This file is a [TOML](https://en.wikipedia.org/wiki/TOML#) formatted file. 
 You can find some examples here: 
- - `config/environments/local/local.node.config.toml`: running a permisionless node
+ - `config/environments/local/local.node.config.toml`: running a permissionless node
   - `config/environments/mainnet/node.config.toml`
   - `config/environments/public/node.config.toml`
   - `test/config/test.node.config.toml`: configuration for a trusted node used in CI
 
   For details about the contents you can read the specifications [here](config-file/node-config-doc.md)
 
-This file is used for trusted and for permisionless nodes. In the case of permissionless node you only need to setup next sections: 
+This file is used for trusted and for permissionless nodes. In the case of permissionless node you only need to setup next sections: 
 
  You could **override values with environment variables**. The variables needs to have next format:
 `ZKEVM_NODE_`[<section in uppercase\>`_`]*<var in uppercase\>`

docs/running_local.md

@@ -100,7 +100,7 @@ make run-approve-pol
     - `Database:` state-db
     - `Host:` localhost
     - `Port:` 5432
-    - `Url:` <postgres://state_user:srare_password@localhost:5432/state-db>
+    - `Url:` <postgres://state_user:state_password@localhost:5432/state-db>
   - zkEVM Node *Pool* Database 
     - `Type:` Postgres DB
     - `User:` pool_user

tools/state/README.md

@@ -10,11 +10,11 @@ This tool allows to rerun a set of batches, you could set a flag to persist chan
 If you want to avoid passing network configuration (`--network` and `--custom-network-file`) you need to provide the L2ChainID (`--l2_chain_id`)
 
 ## Reprocess a set of batches and compare with state database
-This reexecute a batch/batches and check if match the data on DB.
+This re-execute a batch/batches and check if match the data on DB.
 It have some flags to allow:
 - `--write_on_hash_db`: this for each execution create the corresponding MT if possible
 it override state_db
-- `--fist_batch`: first batch to process (default: 1)
+- `--first_batch`: first batch to process (default: 1)
 - `--last_batch`: last batch to process (default: the highest batch on batch table)
 - `--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
@@ -53,4 +53,4 @@ expected output:
 ### Check that the batches from 1000 to  5000 match stateRoot
 ```
  go run ./tools/state/. reprocess -cfg test/config/test.node.config.toml -l2_chain_id 1440 --first_batch_number 1000 --last_batch_number 5000  2> /dev/null
-```
+```