From 24dbf8831edd11a8c75ec5a73b0c82e295566284 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:02:07 +0300 Subject: [PATCH 01/12] typo attester_commitee.md --- docs/src/announcements/attester_commitee.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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). From d7a4eb64e41103b7d074a4d68b25d7b711ce937a Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:02:59 +0300 Subject: [PATCH 02/12] typo 02_deposits.md --- docs/src/guides/advanced/02_deposits.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 From e1418d96ab153b12606cc10350340ab649ada358 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:12:13 +0300 Subject: [PATCH 03/12] typo 11_compression.md --- docs/src/guides/advanced/11_compression.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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) From 7208bfe96e2c080966b1c620bf91bc31ceb0cea6 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:17:40 +0300 Subject: [PATCH 04/12] typo 90_advanced_debugging.md --- docs/src/guides/advanced/90_advanced_debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/guides/advanced/90_advanced_debugging.md b/docs/src/guides/advanced/90_advanced_debugging.md index b2a45bb3ac9a..dffdd46659e0 100644 --- a/docs/src/guides/advanced/90_advanced_debugging.md +++ b/docs/src/guides/advanced/90_advanced_debugging.md @@ -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). From 2bf96e4488fdbc0ede33a452d8d69e2befcc64c4 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:24:59 +0300 Subject: [PATCH 05/12] typo 90_advanced_debugging.md --- docs/src/guides/advanced/90_advanced_debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/guides/advanced/90_advanced_debugging.md b/docs/src/guides/advanced/90_advanced_debugging.md index dffdd46659e0..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: From 2d2e833c3ef67c2a0fd5cc9c59a35d8166f6b95e Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:26:12 +0300 Subject: [PATCH 06/12] typo 91_docker_and_ci.md --- docs/src/guides/advanced/91_docker_and_ci.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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). From ae85b4d1858837348fc07247b2b2cbc788f24f24 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:36:27 +0300 Subject: [PATCH 07/12] typo 09_treeless_mode.md --- docs/src/guides/external-node/09_treeless_mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From 362b947876298a96f9b28d44d6f2b965809191af Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:53:05 +0300 Subject: [PATCH 08/12] typo overview.md --- docs/src/specs/data_availability/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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). From a22e45f896e505451b1ec8cdcf5835834f5f160c Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:57:38 +0300 Subject: [PATCH 09/12] typo boojum_function_check_if_satisfied.md --- docs/src/specs/prover/boojum_function_check_if_satisfied.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From f63c18e4605dccab3287ce6436abeeb694770495 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 15:58:34 +0300 Subject: [PATCH 10/12] typo circuit_testing.md --- docs/src/specs/prover/circuit_testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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>) From 641c9e6b4538a4fdcaaa32f42e325d48a87c2fb0 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 16:01:58 +0300 Subject: [PATCH 11/12] typo interop.md --- docs/src/specs/zk_chains/interop.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From 995e47e420eda0cac53f987ce1570bf606ab9981 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Sun, 24 Nov 2024 16:06:35 +0300 Subject: [PATCH 12/12] typo shared_bridge.md --- docs/src/specs/zk_chains/shared_bridge.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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: