diff --git a/docs/src/announcements/attester_commitee.md b/docs/src/announcements/attester_commitee.md index 148e51a4f976..7764f2fead56 100644 --- a/docs/src/announcements/attester_commitee.md +++ b/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). diff --git a/docs/src/guides/advanced/02_deposits.md b/docs/src/guides/advanced/02_deposits.md index 4018fed46325..7b110959bad5 100644 --- a/docs/src/guides/advanced/02_deposits.md +++ b/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 diff --git a/docs/src/guides/advanced/11_compression.md b/docs/src/guides/advanced/11_compression.md index 957d6cbb51e0..4593940cb3fb 100644 --- a/docs/src/guides/advanced/11_compression.md +++ b/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) diff --git a/docs/src/guides/advanced/90_advanced_debugging.md b/docs/src/guides/advanced/90_advanced_debugging.md index b2a45bb3ac9a..5ba9f6c9ffc8 100644 --- a/docs/src/guides/advanced/90_advanced_debugging.md +++ b/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). diff --git a/docs/src/guides/advanced/91_docker_and_ci.md b/docs/src/guides/advanced/91_docker_and_ci.md index 885d3155dd6c..b5b42e1ae83a 100644 --- a/docs/src/guides/advanced/91_docker_and_ci.md +++ b/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). diff --git a/docs/src/guides/external-node/09_treeless_mode.md b/docs/src/guides/external-node/09_treeless_mode.md index ceeea6f86c67..1b4c30d9ce29 100644 --- a/docs/src/guides/external-node/09_treeless_mode.md +++ b/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. diff --git a/docs/src/specs/data_availability/overview.md b/docs/src/specs/data_availability/overview.md index d2a5f0778967..5b27d1521c96 100644 --- a/docs/src/specs/data_availability/overview.md +++ b/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). diff --git a/docs/src/specs/prover/boojum_function_check_if_satisfied.md b/docs/src/specs/prover/boojum_function_check_if_satisfied.md index 48fa095637d6..8f663999ab31 100644 --- a/docs/src/specs/prover/boojum_function_check_if_satisfied.md +++ b/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. diff --git a/docs/src/specs/prover/circuit_testing.md b/docs/src/specs/prover/circuit_testing.md index 159d908642ff..2671ebe8f7f8 100644 --- a/docs/src/specs/prover/circuit_testing.md +++ b/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>) diff --git a/docs/src/specs/zk_chains/interop.md b/docs/src/specs/zk_chains/interop.md index 947742909b8d..d82d26118b18 100644 --- a/docs/src/specs/zk_chains/interop.md +++ b/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. diff --git a/docs/src/specs/zk_chains/shared_bridge.md b/docs/src/specs/zk_chains/shared_bridge.md index b43d3082b621..f48694c59399 100644 --- a/docs/src/specs/zk_chains/shared_bridge.md +++ b/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: