Merge branch 'main' into main

core/tests/loadnext/README.md

@@ -8,7 +8,7 @@ The general flow is as follows:
 - The master account performs an initial deposit to L2
 - Paymaster on L2 is funded if necessary
 - The L2 master account distributes funds to the participating accounts (`accounts_amount` configuration option)
-- Each account continiously sends L2 transactions as configured in `contract_execution_params` configuration option. At
+- Each account continuously sends L2 transactions as configured in `contract_execution_params` configuration option. At
   any given time there are no more than `max_inflight_txs` transactions in flight for each account.
 - Once each account is done with the initial deposit, the test is run for `duration_sec` seconds.
 - After the test is finished, the master account withdraws all the remaining funds from L2.

core/tests/ts-integration/README.md

@@ -134,7 +134,7 @@ finalization: it make take several hours to generate a proof and send it onchain
 Because of that, framework supports "fast" and "long" modes. `TestMaster` objects have `isFastMode` method to determine
 which mode is currently being used.
 
-If you're going to write a test that can make test run duration longer, it is adviced to guard the "long" part with the
+If you're going to write a test that can make test run duration longer, it is advised to guard the "long" part with the
 corresponding check.
 
 By default, "long" mode is assumed, and to enable the "fast" mode one must set the `ZK_INTEGRATION_TESTS_FAST_MODE`

docs/advanced/02_deposits.md

@@ -162,7 +162,7 @@ The zk server (that you started with `zk server` command) is listening on events
 ) and adds them to the postgres database (into `transactions` table).
 
 You can actually check it - by running the psql and looking at the contents of the table - then you'll notice that
-transaction was succesfully inserted, and it was also marked as 'priority' (as it came from L1) - as regular
+transaction was successfully inserted, and it was also marked as 'priority' (as it came from L1) - as regular
 transactions that are received by the server directly are not marked as priority.
 
 You can verify that this is your transaction, by looking at the `l1_block_number` column (it should match the

docs/advanced/03_withdrawals.md

@@ -81,7 +81,7 @@ This is a good opportunity to talk about system contracts that are automatically
 list here
 [in github](https://github.com/matter-labs/era-system-contracts/blob/436d57da2fb35c40e38bcb6637c3a090ddf60701/scripts/constants.ts#L29)
 
-This is the place were we specify that `bootloader` is at address 0x8001, `NonceHolder` at 0x8003 etc.
+This is the place where we specify that `bootloader` is at address 0x8001, `NonceHolder` at 0x8003 etc.
 
 This brings us to
 [L2EthToken.sol](https://github.com/matter-labs/era-system-contracts/blob/main/contracts/L2EthToken.sol) that has the

docs/advanced/bytecode_compression.md

@@ -31,7 +31,7 @@ Dictionary would be:
 3 -> 0xC (count: 1)
 ```
 
-Note that '1' maps to '0xD', as it occurs twice, and first occurrence is earlier than first occurence of 0xB, that also
+Note that '1' maps to '0xD', as it occurs twice, and first occurrence is earlier than first occurrence of 0xB, that also
 occurs twice.
 
 Compressed bytecode:

docs/advanced/contracts.md

@@ -32,7 +32,7 @@ a bunch of registers. More details on this will be written in the future article
 Having a different VM means that we must have a separate compiler [zk-solc](https://github.com/matter-labs/zksolc-bin) -
 as the bytecode that is produced by this compiler has to use the zkEVM specific opcodes.
 
-While having a separte compiler introduces a bunch of challenges (for example, we need a custom
+While having a separate compiler introduces a bunch of challenges (for example, we need a custom
 [hardhat plugins](https://github.com/matter-labs/hardhat-zksync) ), it brings a bunch of benefits too: for example it
 allows us to move some of the VM logic (like new contract deployment) into System contracts - which allows faster &
 cheaper modifications and increased flexibility.

docs/advanced/prover.md

@@ -86,7 +86,7 @@ pub fn select<F: SmallField, CS: ConstraintSystem<F>>(
 ```
 
 And then there is a block of code for witness evaluation (let's skip it for now), and the final block that adds the gate
-to the constrain system `cs`:
+to the constraint system `cs`:
 
 ```rust
     if <CS::Config as CSConfig>::SetupConfig::KEEP_SETUP {
@@ -204,7 +204,7 @@ filled with concrete values.
 
 ### CsAllocatable
 
-Implements CsAllocatable - which allows you to directly 'allocate' this struct within constraing system (similarly to
+Implements CsAllocatable - which allows you to directly 'allocate' this struct within constraint system (similarly to
 how we were operating on regular 'Variables' above).
 
 ### CSSelectable

docs/advanced/zk_intuition.md

@@ -7,7 +7,7 @@ understanding. We're leaving out a lot of details to keep things brief.
 
 In our case, the prover takes public input and witness (which is huge - you'll see below), and produces a proof, but the
 verifier takes (public input, proof) only, without witness. This means that the huge witness doesn't have to be
-submitted to L1. This property can be used for many things, like privacy, but here we use it to ipmlement an efficient
+submitted to L1. This property can be used for many things, like privacy, but here we use it to implement an efficient
 rollup that publishes the least required amount of data to L1.
 
 ## Basic overview
@@ -85,7 +85,7 @@ located in a module [zksync core witness]. However, for the new proof system, th
 new location called [separate witness binary].
 
 Inside this new location, after the necessary data is fetched from storage, the witness generator calls another piece of
-code from [zkevm_test_harness witness] named `run_with_fixed_params`. This code is responsible for createing the
+code from [zkevm_test_harness witness] named `run_with_fixed_params`. This code is responsible for creating the
 witnesses themselves (which can get really HUGE).
 
 ## Generating the Proof
@@ -139,8 +139,7 @@ version 1.4.0.
 
 [witness_example]:
   https://github.com/matter-labs/era-zkevm_test_harness/tree/main/src/witness/individual_circuits/decommit_code.rs#L24
-[verifier]:
-  https://github.com/matter-labs/zksync-2-contracts/blob/d9785355518edc7f686fb2c91ff7d1caced9f9b8/ethereum/contracts/zksync/Plonk4VerifierWithAccessToDNext.sol#L284
+[verifier]: https://github.com/matter-labs/era-contracts/blob/main/ethereum/contracts/zksync/Verifier.sol
 [bellman repo]: https://github.com/matter-labs/bellman
 [bellman cuda repo]: https://github.com/matter-labs/era-bellman-cuda
 [example ecrecover circuit]:

infrastructure/protocol-upgrade/src/transaction.ts

@@ -60,7 +60,7 @@ export interface L2CanonicalTransaction {
     // is to be passed to account and any changes to its structure
     // would mean a breaking change to these accounts. In order to prevent this,
     // we should keep some fields as "reserved".
-    // It is also recommneded that their length is fixed, since
+    // It is also recommended that their length is fixed, since
     // it would allow easier proof integration (in case we will need
     // some special circuit for preprocessing transactions).
     reserved: [BigNumberish, BigNumberish, BigNumberish, BigNumberish];