Merge pull request 0xPolygon#613 from 0x3lden/main

Fixes typos and reformulates unclear sentences

Author: EmpieichO

docs/zkEVM/architecture/proving-system/execution-trace-design.md

@@ -4,7 +4,7 @@ The intention is to ensure that each row of an execution trace contains all data
 
 **Notation**
 
-Since execution traces are created in the context of state machines, columns of a execution trace are also referred to as _registries_.
+Since execution traces are created in the context of state machines, columns of an execution trace are also referred to as _registries_.
 
 A registry $\texttt{A}$ is denoted by $\texttt{A} = ( a_0, a_1, ... , a_{2^{k}-1})$, where each $a_{i+1}$ is the value in $\texttt{A}$ subsequent to $a_i$. Denote this next value in $\texttt{A}$ by $a'$. That is, $a' = a_{i+1}$.
 
@@ -123,7 +123,7 @@ $$
 \texttt{OP2}:\ c' = a + b + c + a' + b'
 $$
 
-The computation's final outcome is in this case placed in column $\texttt{C}$, as shown inthe table below.
+The computation's final outcome is in this case placed in column $\texttt{C}$, as shown in the table below.
 
 ![Figure: ](../../../img/zkEVM/prover-operands-alternative.png)
 

docs/zkEVM/architecture/proving-system/json-rpc-to-proof.md

@@ -178,7 +178,7 @@ The `validateTx()` function performs the following preliminary checks:
 
 1. The transaction IP address has a valid format.
 
-2. The transaction fields are properly signed (in both current and pre-EIP-155). EIP- 155 states that we must include the `chainID` in the hash of the data to be signed (which is an anti-replay attack protection).
+2. The transaction fields are properly signed (in both current and pre-EIP-155). EIP-155 states that we must include the `chainID` in the hash of the data to be signed (which is an anti-replay attack protection).
 
 3. The transaction’s `chainID` is the same as the pool’s `chainID` (which is the `chainID` of the L2 Network) whenever `chainID` is not zero.
 

docs/zkEVM/architecture/proving-system/polynom-identity-lang.md

@@ -132,9 +132,7 @@ Publicly known values, or _publics_, are not only important in the proving phase
 
 As seen in the previous figure above, _publics_ form part of the verfier's inputs. And, similar to the above pasword protocol, these _publics_ are uniquely related to the executor's input program.
 
-Note that all values in PIL are, by default, considered private.
-
-By default, all values in PIL are considered private. However, any specific can be made public by using the keyword _public_.
+By default, all values in PIL are considered private. However, any specific value can be made public by using the keyword _public_.
 
 ![Figure: ](../../../img/zkEVM/prover-exec-trace-hash-and-verifier.png)
 

docs/zkEVM/architecture/zkprover/hashing-state-machines/index.md

@@ -18,7 +18,7 @@ operating on a fixed number $b$ of bits.
 
 The array of $b$ bits that $f$ keeps transforming is called the _state_, and $b$ is called the _width_ of the state.
 
-The state array is split into two chunks, one with $r$ bits and the other with $c$ bits. The width $b = r + c$,_ where_ $r$ is called the _bitrate_ (or simply _rate_) and $c$ is called the _capacity_.
+The state array is split into two chunks, one with $r$ bits and the other with $c$ bits. The width $b = r + c$, where $r$ is called the _bitrate_ (or simply _rate_) and $c$ is called the _capacity_.
 
 ## Sponge construction phases
 

docs/zkEVM/architecture/zkprover/hashing-state-machines/keccak-framework.md

@@ -1,4 +1,4 @@
-The zkEVM, as an L2 zk-Rollup for Ethereum, employs the Keccak hash function to achieve seamless compatibility with the Ethereum blockchain at Layer 1. However, rathe four state machines relate implementing the Keccak-256 hash function as a single state machine, the zkEVM does so in a framework of four state machines. The four state machines relate as follows:
+The zkEVM, as an L2 zk-Rollup for Ethereum, employs the Keccak hash function to achieve seamless compatibility with the Ethereum blockchain at Layer 1. However, rather than implementing a single state machine that performs four different tasks, the zkEVM does so in a framework of four state machines:
 
 1. The Padding-KK SM is used for padding purposes, as well as validation of hash-related computations pertaining to the Main SM's queries. As depicted in the figure below, the Padding-KK SM is the Main SM's gateway to the Keccak hashing framework.
 

docs/zkEVM/architecture/zkprover/hashing-state-machines/paddingkk-sm.md

@@ -1,6 +1,6 @@
 All Keccak-related state machines are accessed through the Padding-KK state machine. It is therefore responsible for handling queries from the Main state machine. Common queries are requests for digests of messages, together with validation of these digests.
 
-In this document, the internal mechanism of the Padding-KK SM is described. How it validates the validity of hash values, input string lengths, and input string readings to ensure that padding requirements are followed.
+This document describes the internal mechanism of the Padding-KK SM. It explains how the state machine validates hash values, input string lengths, and input string readings to ensure that padding requirements are followed.
 
 First, keep in mind that the Padding-KK SM's operations are byte-based, whereas the Keccak-F SM's actions are bit-based. This discrepancy in string formats is handled by the Padding-KK-Bit SM.
 

docs/zkEVM/spec/pil/simple-example.md

@@ -79,7 +79,7 @@ In the zkEVM context, these polynomials would be committed by the Main state mac
 
 The above design of the _Multiplier_ program, as represented by its execution trace, does not scale easily to more complex operations. The number of polynomials (or number of columns) grows linearly with the number of operations that needs to be performed.
 
-For example, if we were design a Multiplier program that computes $2^{10}$ operation, the above design would require $2^{10}$ committed polynomials, which is far from being practical.
+For example, if we were to design a Multiplier program that computes $2^{10}$ operation, the above design would require $2^{10}$ committed polynomials, which is far from being practical.
 
 Here's a more practical design, which reduces the $2^{10}$ committed polynomials to only 3 polynomials;