Apply suggestions from code review

Co-authored-by: Dra Murphy <149679879+kmurphypolygon@users.noreply.github.com>

Author: EmpieichO

docs/zkEVM/architecture/effective-gas/implement-egp-strat.md

@@ -74,16 +74,16 @@ $$
 
 where $\texttt{DataCost}$ is the cost in gas for data stored in L1.
 
-The cost of data in Ethereum varies according to whether it involves zero bytes or non-zero bytes. In particular, non-zero bytes cost $16$ gas units, while zero bytes cost $4$ gas unints. 
+The cost of data in Ethereum varies according to whether it involves zero bytes or non-zero bytes. In particular, non-zero bytes cost $16$ gas units, while zero bytes cost $4$ gas units. 
 
-Also, recall that the computation of the cost for _non-zero bytes_ must take into account the constant data which always appear in a transaction but not included in the RLP:
+Also, recall that the computation of the cost for _non-zero bytes_ must take into account constants that appear in transactions but are not included in the RLP, which includes:
 
 - The signature, which consists of $65$ bytes.
-- The previously defined $\texttt{EffectivePercentageByte}$, which consists in a single byte. 
+- The previously defined $\texttt{EffectivePercentageByte}$, which consists of a single byte. 
 
 This results in a total of $66$ constantly present bytes.
 
-Taking all in consideration, $\texttt{DataCost}$ can be computed as:
+Taking everything into consideration, $\texttt{DataCost}$ can be computed as:
 
 $$
 \texttt{DataCost} = (\texttt{TxConstBytes} + \texttt{TxNonZeroBytes}) \cdot \texttt{NonZeroByteGasCost} \\
@@ -94,9 +94,9 @@ where $\texttt{TxNonZeroBytes}$ represents the count of non-zero bytes in a raw
 
 #### Computational costs
 
-Costs associated with transaction execution is denoted by $\texttt{ExecutionCost}$, and it is measured in gas.
+Costs associated with transaction execution is denoted by $\texttt{ExecutionCost}$, and is measured in gas.
 
-In contrast to costs for data availability, calculating computational costs necessecitates transactions to be executed.
+In contrast to costs for data availability, calculating computational costs requires executing transactions.
 
 So then,
 
@@ -144,11 +144,11 @@ $$
 \texttt{SignedGasPrice} > \texttt{BreakEvenGasPrice}.
 $$
 
-However, a  problem arises:
+However, a problem arises:
 
 In the RPC component, we’re only pre-executing the transaction, meaning we’re using an incorrect state root. Consequently, the $\texttt{GasUsed}$ is only an approximation.
 
-This implies that we need to multiply the result by a chosen factor before comparing it to the signed price.
+This implies that we need to multiply the result by a chosen factor before comparing it to the signed price to hedge against unforeseen costs.
 
 This ensures that the costs are covered in case more gas is ultimately required to execute the transaction. This factor is named $\texttt{BreakEvenFactor}$.
 
@@ -160,7 +160,7 @@ $$
 
 then it is safe to accept the transaction.
 
-Observe that we still need to introduce gas price prioritization, which will be covered later on.
+Observe that we still need to introduce gas price prioritization, which we explain later.
 
 ### Example (Breakeven gas price)
 
@@ -170,11 +170,11 @@ The figure below depicts the current situation.
 
 ![Figure: Timeline current L1GasPrice](../../../img/zkEVM/timeline-current-l1gasprice.png)
 
-Suppose the user sends a transaction that has $200$ non-zero bytes, including the constant ones and $100$ zero bytes. 
+Suppose the user sends a transaction that has $200$ non-zero bytes, including the constants and $100$ zero bytes. 
 
-Moreover, at the time of pre-executing the transaction, which is done without getting an out-of-counters (OOC) error, $60,000$ gas units are consumed.
+Moreover, on pre-executing the transaction without an out-of-counters (OOC) error, $60,000$ gas units are consumed.
 
-Recall that, since we are using a "wrong" state root, this gas is only an estimation. 
+Recall that, since we are using a "wrong" state root, this amount is only an estimation. 
 
 Hence, using the previously explained formulas, the total transaction cost is:
 
@@ -195,7 +195,7 @@ $$
 
 We have introduced a $\texttt{NetProfit}$ value of $1.2$, indicating a target of a $20\%$ gain in this process. 
 
-At a first glance, we might conclude acceptance since:
+At first glance, we might conclude the transaction has been accepted:
 
 $$
  \texttt{SignedGasPrice} = 3.3 > 2.52
@@ -209,7 +209,7 @@ $$
 \texttt{SignedGasPrice} = 3.3 > 3.276 = 2.52 · 1.3 = \texttt{BreakEvenGasPrice} \cdot \texttt{BreakEvenFactor}
 $$
 
-Consequently, we decide to accept the transaction.
+Consequently, the system accepts the transaction.
 
 ### Example (Breakeven factor)
 
@@ -223,11 +223,11 @@ $$
 
 However, let's assume the correct execution at the time of sequencing consumes $35,000$ gas.
 
-If we recompute $\texttt{BreakEvenGasPrice}$ using this updated used gas, we get $3.6\ \texttt{GWei/Gas}$, which is way higher than the original one. 
+If we recompute $\texttt{BreakEvenGasPrice}$ using this updated used gas, we get $3.6\ \texttt{GWei/Gas}$, which is way higher than the original estimation. 
 
 That means we should have charged the user a higher gas price in order to cover the whole transaction cost, standing at $105,000\ \texttt{GWei}$.
 
-But, since we are accepting all the transactions that sign more than $2.85$ of gas price, we do not have any margin to increase more. 
+But, since we are accepting all the transactions that sign more than $2.85$ of gas price, we do not have any margin to increase it. 
 
 In the worst case we are losing:
 
@@ -249,4 +249,4 @@ $$
 105, 000 − 35, 000 · 3.27 < 0
 $$
 
-**Final Note**: In the above example, even though we assumed that a decrease in the $\texttt{BreakEvenGasPrice}$ is a result of executing with a correct state root, it can also decrease significantly due to a substantial reduction in $\texttt{L1GasPrice}$.
+**Final Note**: In the above example, even though we assume that a decrease in the $\texttt{BreakEvenGasPrice}$ is a result of executing with a correct state root, it can also decrease significantly due to a substantial reduction in $\texttt{L1GasPrice}$.

docs/zkEVM/architecture/effective-gas/index.md

@@ -6,7 +6,7 @@ Now that the EGP is in place, you can reduce any chance for a transaction revert
 
 ## How gas fees work in Ethereum
 
-There are two adjustable parameters, in Ethereum, that have a direct impact on transaction gas fees:
+In Ethereum, there are two adjustable parameters that have a direct impact on transaction gas fees:
 
 - The $\texttt{gasLimit}$, which is the maximum amount of gas units the user is willing to buy in order for their transactions to be included in a block and processed on chain.
 - The $\texttt{gasPrice}$, that is, the amount of ETH a user is willing to pay for 1 gas unit. For instance, a gas price of 10 Gwei means the user is willing to pay 0.00000001 ETH for each unit of gas.

docs/zkEVM/architecture/effective-gas/user-tx-flow/rpc-flow-egp.md

@@ -59,16 +59,15 @@ The RPC flow is summarized in the figure below.
 
 ## Example (RPC tx flow)
 
-Consider a scenario where a user sends a query for a suggested gas price during a certain 5-minute interval, as shown in the figure below.
+Consider a scenario where a user sends a query for a suggested gas price during a 5-minute interval, as shown in the figure below.
 
-Values of L1 gas prices polled every 5 seconds are displayed above the timeline, while the corresponding L2 gas prices are depicted below the timeline. See the figure below.
+Values of L1 gas prices, polled every 5 seconds, are displayed above the timeline, while the corresponding L2 gas prices are depicted below the timeline. See the figure below.
 
 ![Figure: Suggested gas price (first)](../../../../img/zkEVM/timeline-current-l1gasprice-suggstd.png)
 
-
 1. Observe that, in the above timeline, the user sends a query at the time indicated by the dotted-arrow on the left. And that's when $\texttt{L1GasPrice}$ is $19$.
 
-    The RPC node therefore responds with a $2.85 \texttt{ GWei/Gas}$, as the value of the suggested L2 gas price.
+    The RPC node responds with a $2.85 \texttt{ GWei/Gas}$, as the value of the suggested L2 gas price.
 
     This value is obtained as follows:
 
@@ -78,7 +77,7 @@ Values of L1 gas prices polled every 5 seconds are displayed above the timeline,
 
     where $0.15$ is the zkEVM's suggested factor.
 
-2. Let's suppose the user sends a transaction signed with a gas price of $3$. That is, $\texttt{SignedGasPrice} = 3$
+2. Let's suppose the user sends a transaction signed with a gas price of $3$. That is, $\texttt{SignedGasPrice} = 3$.
 
     However, by the time the user sends the signed transaction, the L1 gas price is no longer $19$ but $21$. And its correponding suggested gas price is $\mathtt{3.15 = 21 \cdot 0.15}$.
 
@@ -116,13 +115,13 @@ Values of L1 gas prices polled every 5 seconds are displayed above the timeline,
     \texttt{BreakEvenGasPrice} \cdot \texttt{BreakEvenFactor} = 2.52 \cdot 1.3 =  3.276
     $$
 
-    And since $\texttt{SignedGasPrice}  = 3 <  3.276$, the transaction is not immediately stored in the pool of transaction.
+    And since $\texttt{SignedGasPrice}  = 3 <  3.276$, the transaction is not immediately stored in the transaction pool.
 
 6. However, since
 
     $$
     \texttt{SignedGasPrice} = 3 ≥ 2.85 = \texttt{GasPriceSuggested}
     $$
 
-    and despite the risk of the network sponsoring the transaction, it is included into the transaction pool.
+    and despite the risk of the network sponsoring the transaction, it is included in the transaction pool.
 

docs/zkEVM/architecture/effective-gas/user-tx-flow/sequencer-flow-egp.md

@@ -34,7 +34,7 @@ In this phase of the end-to-end transaction flow, transactions go through differ
    ![Figure: Sequencer flow](../../../../img/zkEVM/tx-flow-seq-component.png)
 
 
-### Example (Sequencer Flow)
+### Example (Sequencer flow)
 
 Let's continue the numerical example we have been using throughout this document.
 
@@ -53,7 +53,7 @@ $$
 
     Recall how we previously obtained the $\texttt{BreakEvenGasPriceRPC}$ of $2.52\ \texttt{GWei/Gas}$.
 
-    According to the above figure, the network recommends a gas price of $3$, which corresponds to an L1 gas price of $20$.
+    According to the figure above, the network recommends a gas price of $3$, which corresponds to an L1 gas price of $20$.
 
     This results in the following priority factor:
 
@@ -93,15 +93,15 @@ $$
 
     which is bigger than the RPC-estimated gas of $60,000$.
 
-4. With the new $\texttt{GasUsedNew}$, an adjusted effective gas price ($\texttt{NEGP}$) can be computed in the following steps.
+4. With the new $\texttt{GasUsedNew}$, an adjusted effective gas price ($\texttt{NEGP}$) can be computed by the following steps.
 
     Firstly, the total transaction cost:
 
     $$
     \texttt{TxCostNew} = (200 · 16 + 100 · 4) · 20 + 95,000 · 20 · 0.04 = 148,000 \ \texttt{GWei}
     $$
 
-    It is assumed that the transaction has 200 non-zero bytes and 100 zero bytes.
+    We assume that the transaction has 200 non-zero bytes and 100 zero bytes.
 
     Secondly, the new breakeven gas price: 
 
@@ -122,7 +122,7 @@ $$
     \end{aligned}
     $$
 
-    Observe that the transaction cost is way higher than the RPC-estimated one of $126,000$ even when the L1 gas price has decreased from 21 to 20 due to a huge increase in gas.
+    Observe that the transaction cost is much higher than the RPC-estimation of $126,000$, even when the L1 gas price has decreased from 21 to 20 due to a huge increase in gas.
 
 5. Observe that there is a significant deviation between both effective gas prices: