From 5cb50325322333b5c5f4bbadc409bfa4e9a676ac Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Mon, 13 Nov 2023 07:38:42 +0200 Subject: [PATCH] fix: several typos in the docs (#1028) * fix typos README.md * fix typo README.md * fix typos Bytecode_Circuit.md * fix typo EVM_Circuit.md * fix typo Keccak_Circuit.md --- aggregator/README.md | 12 ++++++------ bus-mapping/README.md | 2 +- docs/Bytecode_Circuit.md | 4 ++-- docs/EVM_Circuit.md | 4 ++-- docs/Keccak_Circuit.md | 6 +++--- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/aggregator/README.md b/aggregator/README.md index c201ac5b2b..b06c636323 100644 --- a/aggregator/README.md +++ b/aggregator/README.md @@ -36,7 +36,7 @@ c_i.post_state_root == c_{i+1}.prev_state_root for $i \in [1, k-1]$. ## Padded chunk -A __padded chunk__ is a chunk that repeats last valid chunk. It is used for padding. +A __padded chunk__ is a chunk that repeats the last valid chunk. It is used for padding. If $k< n$, $(n-k)$ padded chunks are padded to the list. A padded chunk has the same data fields as the last real chunk, and the parameters are set as - state root before this chunk: `c_{k}.prev_state_root` - state root after this chunk: `c_{k}.post_state_root` @@ -97,7 +97,7 @@ for i in 1 ... n chunk_pi_hash := keccak(chain_id || prev_state_root || post_state_root || withdraw_root || chunk_data_hash) ``` -This is done by compute the RLCs of chunk[i]'s data_hash for `i=0..k`, and then check the RLC matches the one from the keccak table. +This is done by computing the RLCs of chunk[i]'s data_hash for `i=0..k`, and then check the RLC matches the one from the keccak table. 4. chunks are continuous when they are not padded: they are linked via the state roots. @@ -106,7 +106,7 @@ for i in 1 ... k-1 c_i.post_state_root == c_{i+1}.prev_state_root ``` -5. All the chunks use a same chain id. __Static__. +5. All the chunks use the same chain id. __Static__. ``` for i in 1 ... n batch.chain_id == chunk[i].chain_id @@ -119,7 +119,7 @@ for i in 1 ... n: chunk[i]'s chunk_pi_hash_rlc_cells == chunk[i-1].chunk_pi_hash_rlc_cells ``` This is done via comparing the `data_rlc` of `chunk_{i-1}` and ` chunk_{i}`. -7. the hash input length are correct +7. the hash input length is correct - first MAX_AGG_SNARKS + 1 hashes all have 136 bytes input - batch's data_hash length is 32 * number_of_valid_snarks 8. batch data hash is correct w.r.t. its RLCs @@ -131,7 +131,7 @@ This is done via comparing the `data_rlc` of `chunk_{i-1}` and ` chunk_{i}`. ![Dynamic_inputs](./figures/hash_table.jpg) -Our keccak table uses $2^{19}$ rows. Each keccak round takes `300` rows. When the number of round is is less than $2^{19}/300$, the cell manager will fill in the rest of the rows with dummy hashes. +Our keccak table uses $2^{19}$ rows. Each keccak round takes `300` rows. When the number of round is less than $2^{19}/300$, the cell manager will fill in the rest of the rows with dummy hashes. The only hash that uses dynamic number of rounds is the last hash. Suppose we target for `MAX_AGG_SNARK = 10`. Then, the last hash function will take no more than `32 * 10 /136 = 3` rounds. @@ -154,4 +154,4 @@ For the output of the final data hash |9,10 | 64 | 0, 0, 1| Additional checks for dummy chunk -- if `is_padding` for `i`-th chunk, we constrain `chunk[i]'s chunk_pi_hash_rlc_cells == chunk[i-1].chunk_pi_hash_rlc_cells` \ No newline at end of file +- if `is_padding` for `i`-th chunk, we constrain `chunk[i]'s chunk_pi_hash_rlc_cells == chunk[i-1].chunk_pi_hash_rlc_cells` diff --git a/bus-mapping/README.md b/bus-mapping/README.md index e0cbea24da..342dbfc21b 100644 --- a/bus-mapping/README.md +++ b/bus-mapping/README.md @@ -27,7 +27,7 @@ prover to pick any location here and in the EVM proof confirm it is correct. time. It checks the validity of these opcodes. It also confirms that for each of these opcodes the state proof performed the correct operation. -Only after verifying both proofs are we confident that that Ethereum block +Only after verifying both proofs are we confident that the Ethereum block is executed correctly. ### Bus Mapping diff --git a/docs/Bytecode_Circuit.md b/docs/Bytecode_Circuit.md index 798fa13f3f..666140a9ce 100644 --- a/docs/Bytecode_Circuit.md +++ b/docs/Bytecode_Circuit.md @@ -15,7 +15,7 @@ The EVM Circuit needs to lookup to the bytecode table that stores the correct by |RLC of hash's little-endian bytes using evm_word randomness|BytecodeFieldTag::Header|0|0|len of bytes| |RLC of hash's little-endian bytes using evm_word randomness|BytecodeFieldTag::Byte|idx|true when the byte is not an argument to a PUSHx instruction|byte| -Here `Header` is used to seperate bytecodes. +Here `Header` is used to separate bytecodes. ## Purpose of the Bytecode Circuit @@ -98,5 +98,5 @@ Here - when `tag` is `byte`, then lookup to push_table for `(value, push_data_size)` - correct propagation of each row within one bytecode - - when `tag` transits from `byte` to `byte`, then `length` and `hash` remain the same, `index` increse by 1, `value_rlc` accumulates, and for push data `push_data_left` decay by 1, for code `push_data_left` remains the same as `push_data_size` + - when `tag` transits from `byte` to `byte`, then `length` and `hash` remain the same, `index` increases by 1, `value_rlc` accumulates, and for push data `push_data_left` decay by 1, for code `push_data_left` remains the same as `push_data_size` diff --git a/docs/EVM_Circuit.md b/docs/EVM_Circuit.md index fd6f0e3f98..ecf32d1179 100644 --- a/docs/EVM_Circuit.md +++ b/docs/EVM_Circuit.md @@ -29,7 +29,7 @@ Analogously, in EVM Circuit, we build execution steps according to the st ## Architecture -We decompose the execution trace into execution steps and impose constraints for each step/step state transition. A `Step` contains two parts: `StepState` carries the execution step and its context information; and `CellManager` helps to fill the step's information as witnesses into the circuit's cells. An API layer `ConstraintBuilder` is built upon the backend proof system (Halo2) to impose constraints. The oveall architecture looks as follows: +We decompose the execution trace into execution steps and impose constraints for each step/step state transition. A `Step` contains two parts: `StepState` carries the execution step and its context information; and `CellManager` helps to fill the step's information as witnesses into the circuit's cells. An API layer `ConstraintBuilder` is built upon the backend proof system (Halo2) to impose constraints. The overall architecture looks as follows: ```mermaid stateDiagram @@ -362,4 +362,4 @@ For RETURNDATACOPY opcode, EVM Circuit does the following type of constraint che - `SameContextGadget` - opcodeID checks: opId $==$ OpcodeId(0x3e); - state transition: rw_counter+, stack\_pointer+3, pc+1, gas -(op_cost+memory expansion cost), memory expand to next memory word size. - \ No newline at end of file + diff --git a/docs/Keccak_Circuit.md b/docs/Keccak_Circuit.md index e8a827bf9b..07d23cd203 100644 --- a/docs/Keccak_Circuit.md +++ b/docs/Keccak_Circuit.md @@ -65,7 +65,7 @@ Cyclic shift offset constants $r[x,y]$ are picked according to the following tab | $y=4$ | 56 | 14 | 18 | 2 | 61 | | $y=3$ | 21 | 8 | 41 | 45 | 15 | -Round constants $RC[k]$ are also given, in hexiadecimal notion it looks like: +Round constants $RC[k]$ are also given, in hexadecimal notion it looks like: $$\begin{array}{ll} RC[ 0] & \verb"0x0000000000000001" @@ -226,7 +226,7 @@ The parts splitted from the word is then determined bit-by-bit from `target_size - `uniform` is true, then the remaining `rot`-sized bits [63-`rot`+1,...,63] are divided by `part_size` plus a remainder, and first 64-`rot` bits are determined by a section compensating previous remainder, plus divide by `part_size`, and plus the remainder from `target_size` division; - `uniform` is false, then the remaining `rot`-sized bits [63-`rot`+1,...,63] are divided by `part_size` plus remainder, and first 64-`rot` bits determined by `part_size` plus a remainder. -The way we do the above split when `uniform` is true enables an optimization shown below, where after rotation the front and tail remainders combined together becomes an inverval of length `part_size`: +The way we do the above split when `uniform` is true enables an optimization shown below, where after rotation the front and tail remainders combined together becomes an interval of length `part_size`: ![split_normalize_true](https://hackmd.io/_uploads/S1V-8qoKn.png) @@ -350,7 +350,7 @@ $$os[i][j]=s[i][j]+bc[(i+4)\mod 5]+\text{rot}(bc[(i+1)\mod 5], 1) $$ and set it #### Rationale - Soundness: Use the symbols in the previous section on Keccak-f permutation function, it can be checked that $C[x]$ is the same as the parity of $A[x,0]+A[x,1]+...+A[x,4]$. So this is what $bc[i]$ checks at the `normalize_6` table lookup step. -In a same rationale, $os[i][j]$ after normalization stands for the parity of $A[x,y]\oplus D[x]$. This normalization is postponed to $\rho/\pi$-step using `normalize_4` table lookup. +In the same rationale, $os[i][j]$ after normalization stands for the parity of $A[x,y]\oplus D[x]$. This normalization is postponed to $\rho/\pi$-step using `normalize_4` table lookup. - Completeness: Since $C[x]$ is the same as the parity of $A[x,0]+A[x,1]+...+A[x,4]$, any selection of witnesses that satisfy original $\theta$-step in the Section on Keccak-f permutation function will pass the constraints. ### rho/pi-step