Fix/corr

docs/src/announcements/attester_commitee.md

@@ -11,7 +11,7 @@ ended up with the same state root hash.
 
 ## Current State
 
-Before starting the L1 integration, we want to ensure that we can to consistently reach the quorum and collect the
+Before starting the L1 integration, we want to ensure that we can consistently reach the quorum and collect the
 signatures in a timely manner. Currently the main node just stores the signatures in the local DB
 (`l1_batches_consensus` table).
 

docs/src/guides/advanced/02_deposits.md

@@ -37,7 +37,7 @@ Now, let's see how many tokens we have:
 ./web3 --rpc-url http://localhost:3050 balance  0x618263CE921F7dd5F4f40C29f6c524Aaf97b9bbd
 ```
 
-Unsurprisingly we have 0 on both - let's fix it by first transferring some tokens on L1:
+Unsurprisingly we have 0 on both - let's fix it by first transferring some tokens to L1:
 
 ```shell
 ./web3 --rpc-url http://localhost:8545 transfer --pk 0x7726827caac94a7f9e1b160f7ea819f172f7b6f9d2a97f992c38edeab82d4110 7.4 to 0x618263CE921F7dd5F4f40C29f6c524Aaf97b9bbd

docs/src/guides/advanced/11_compression.md

@@ -5,7 +5,7 @@
 As we are a rollup - all the bytecodes that contracts used in our chain must be copied into L1 (so that the chain can be
 reconstructed from L1 if needed).
 
-Given the want/need to cutdown on space used, bytecode is compressed prior to being posted to L1. At a high level
+Given the want/need to cut down on space used, bytecode is compressed prior to being posted to L1. At a high level
 bytecode is chunked into opcodes (which have a size of 8 bytes), assigned a 2 byte index, and the newly formed byte
 sequence (indexes) are verified and sent to L1. This process is split into 2 different parts: (1)
 [the server side operator](https://github.com/matter-labs/zksync-era/blob/main/core/lib/utils/src/bytecode.rs#L31)

docs/src/guides/advanced/90_advanced_debugging.md

@@ -11,7 +11,7 @@ You should create the following file in your `$workspaceFolder/.vscode/` called
 import os
 import lldb
 
-# Read the .env file and store the key-value pairs in a array with format ["key=value"]
+# Read the .env file and store the key-value pairs in an array with format ["key=value"]
 env_array = []
 with open(os.path.join("etc/env/l2-inits/dev.init.env")) as f:
     for line in f:
@@ -64,7 +64,7 @@ Afterwards you need to add something like this to your launch.json:
 
 ## Debugging contracts in vscode (using hardhat)
 
-Assuming that you created project in hardhat, that you'd normally test with `hardhat test` - you also also test it with
+Assuming that you created project in hardhat, that you'd normally test with `hardhat test` - you can also test it with
 vscode (which is super powerful - especially as you can have both binaries' debug sessions running in VSCode at the same
 time).
 

docs/src/guides/advanced/91_docker_and_ci.md

@@ -4,7 +4,7 @@ How to efficiently debug CI issues locally.
 
 This document will be useful in case you struggle with reproducing some CI issues on your local machine.
 
-In most cases, this is due to the fact that your local machine has some arifacts, configs, files that you might have set
+In most cases, this is due to the fact that your local machine has some artifacts, configs, files that you might have set
 in the past, that are missing from the CI.
 
 ## Basic docker commands
@@ -48,7 +48,7 @@ You should see something like this:
  ⠿ Container zksync-era-reth-1      Started   0.3s
 ```
 
-Start the docker with the 'basic' imge
+Start the docker with the 'basic' image
 
 ```
 # We tell it to connect to the same 'subnetwork' as other containers (zksync-era_default).

docs/src/guides/external-node/09_treeless_mode.md

@@ -18,7 +18,7 @@ storage. It uses the following 2 sources of hashes:
 - Main L2 node (or more generally, the L2 node that the current node is configured to sync from). Only used if the L1
   data source does not work (e.g., very recent L1 batches may be not yet committed to L1).
 
-If the tree fetcher run concurrently to the Merkle tree, the tree will still compute state root hashes for all batches.
+If the tree fetcher runs concurrently with the Merkle tree, the tree will still compute state root hashes for all batches.
 If the tree is slower than the fetcher (which is expected in most cases), it will compare the computed hash against the
 state root hash from the tree fetcher and crash on a mismatch.
 

docs/src/specs/data_availability/overview.md

@@ -13,7 +13,7 @@ We also [compress](./compression.md) all the data that we send to L1, to reduce
 By posting all the data to L1, we can [reconstruct](./reconstruction.md) the state of the chain from the data on L1.
 This is a key security property of the rollup.
 
-The the chain chooses not to post this data, they become a validium. This makes transactions there much cheaper, but
+If the chain chooses not to post this data, they become a validium. This makes transactions there much cheaper, but
 less secure. Because we use state diffs to post data, we can combine the rollup and validium features, by separating
 storage slots that need to post data from the ones that don't. This construction combines the benefits of rollups and
 validiums, and it is called a [zkPorter](./validium_zk_porter.md).

docs/src/specs/prover/boojum_function_check_if_satisfied.md

@@ -48,7 +48,7 @@ For each row and gate, we need several things.
 Placement is either UniqueOnRow or MultipleOnRow. UniqueOnRow means there is only one gate on the row (typically because
 the gate is larger / more complicated). MultipleOnRow means there are multiple gates within the same row (typically
 because the gate is smaller). For example, if a gate only needs 30 columns, but we have 150 columns, we could include
-five copies fo that gate in the same row.
+five copies of that gate in the same row.
 
 Next, if the placement is UniqueOnRow, we call evaluate_over_general_purpose_columns. All of the evaluations should be
 equal to zero, or we panic.

docs/src/specs/prover/circuit_testing.md

@@ -38,7 +38,7 @@ Now the constraint system is ready! We can start the main part of the test!
 ![Contest(8).png](<./img/circuit_testing/Contest(8).png>)
 
 Here we have hard coded a secret key with its associated public key, and generate a signature. We will test our circuit
-on these inputs! Next we “allocate” these inputs as witnessess:
+on these inputs! Next we “allocate” these inputs as witnesses:
 
 ![Contest(9).png](<./img/circuit_testing/Contest(9).png>)
 

docs/src/specs/zk_chains/interop.md

@@ -38,7 +38,7 @@ The interop process has 7 main steps, each with its substeps:
    it to the MessageRoot.
 6. Receiving the tx on the destination chain
 
-   - On the destination chain the xL2 txs is verified. This means the merkle proof is checked agains the MessageRoot.
+   - On the destination chain the xL2 txs is verified. This means the merkle proof is checked against the MessageRoot.
      This shows the the xL2 txs was indeed sent.
    - After this the txs can be executed. The tx hash is stored in the L2Nullifier contract, so that the txs cannot be
      replayed.

docs/src/specs/zk_chains/shared_bridge.md

@@ -110,7 +110,7 @@ be able to leverage them when available).
 }
 ```
 
-- The `requestL2TransactionTwoBridges` function should be used most of the time when bridging to a chain ( the exeption
+- The `requestL2TransactionTwoBridges` function should be used most of the time when bridging to a chain ( the exception
   is when the user bridges directly to a contract on the L2, without using a bridge contract on L1). The logic of it is
   the following: