Merge pull request 0xPolygon#293 from 0xPolygon/empieichO-docs-review

Draft: Review zkEVM - minor typos

Author: kmurphypolygon

docs/zkEVM/architecture/user-fees.md

@@ -80,15 +80,6 @@ Their corresponding pertinent questions are:
 - How do L2 solutions address and reconcile any discrepancies between the L1 gas schema and the real resource utilization on L2?
 
 
-### Time-related variations
-
-So, how can the fact that the L1 $\texttt{gasPrice}$ varies with time be taken into account?
-
-In order to obtain L1 gas prices, we can poll for it every 5 seconds. As shown in the timeline below, gas prices vary with time.
-
-![Figure: Gas price timeline](../../img/zkEVM/gas-timeline-001.png)
-
-
 ## Gas price suggester
 
 Let's take a quick view of the initial phase of the process, which involves the RPC component of zkEVM.
@@ -104,6 +95,15 @@ See the the picture below for an overview of the pre-execution process.
 ![Figure: RPC tx pre-execution](../../img/zkEVM/rpc-tx-preexec.png)
 
 
+### Time-related variations
+
+So, how can the fact that the L1 $\texttt{gasPrice}$ varies with time be taken into account?
+
+In order to obtain L1 gas prices, we can poll for it every 5 seconds. As shown in the timeline below, gas prices vary with time.
+
+![Figure: Gas price timeline](../../img/zkEVM/gas-timeline-001.png)
+
+
 ### Naïve approach
 
 Let's look at this in two parts; gasPrice suggestion, and transaction sending.
@@ -512,7 +512,10 @@ Recall that, since we are using a "wrong" state root, this gas is only an estima
 Hence, using the previously explained formulas, the total transaction cost is:
 
 $$
-\texttt{TotalTxPrice} = \texttt{DataCost} \cdot \texttt{L1GasPrice} + \texttt{GasUsed} \cdot \texttt{L1GasPrice} \cdot \texttt{L1GasPriceFactor}\\ \implies  \texttt{TotalTxPrice} = (200 · 16 + 100 · 4) · 21 + 60, 000 · 21 · 0.04 = 126, 000\ \texttt{GWei}
+\begin{aligned}
+&\texttt{TotalTxPrice} = \texttt{DataCost} \cdot \texttt{L1GasPrice} + \texttt{GasUsed} \cdot \texttt{L1GasPrice} \cdot \texttt{L1GasPriceFactor}\\
+&\implies  \texttt{TotalTxPrice} = (200 · 16 + 100 · 4) · 21 + 60, 000 · 21 · 0.04 = 126, 000\ \texttt{GWei}
+\end{aligned}
 $$
 
 Observe that the $21$ appearing in the substitution is the $\texttt{L1GasPrice}$ at the time of sending the transaction.
@@ -750,7 +753,7 @@ Hence, if something goes bad in later steps, and the gas consumption deviates si
 
 On the contrary, if the process goes as estimated and the consumed gas is similar to the estimated one, we can reward the user by modifying the previously introduced $\texttt{effectivePercentage}$.
 
-It's important to observe that, among all the transactions stored in the Pool, those that are prioritized at the time of sequencing are the ones with higher $\texttt{effectiveGasPrice}$, due to the prioritization introduced with $\texttt{ratioPriority}$.
+It's important to observe that, among all the transactions stored in the Pool, those that are prioritized at the time of sequencing are the ones with higher $\texttt{effectiveGasPrice}$, due to the prioritization introduced with $\texttt{PriorityRatio}$.
 
 Observe that $\texttt{effectiveGasPrice}$ is not computed in the RPC but in the sequencer. So, it is possible that the suggested gas price at this moment, differs from the one suggested when the user sent the transaction.
 
@@ -851,9 +854,9 @@ Let’s examine the above figure in more detail.
 
     Henceforth, the user is charged the full $\texttt{SignedGasPrice}$, so the Executor will execute the transaction using it, concluding the sequencing process.
 
-    - Conversely, if $\texttt{SignedGasPrice} > \texttt{EEGP}$, there is a room for further adjustment of the gas price that will be charged to the user.
+    - Conversely, if $\texttt{SignedGasPrice} > \texttt{EEGP}$, there's room for further adjustment of the gas price that will be charged to the user.
 
-3. In the previous case, it was necessary to compute a more precise effective gas price based on the accurate amount of gas, denoted as $\texttt{GasUsedNew}$, obtained during the transaction’s execution using the correct state root at the time of sequencing transactions (which was not known earlier for straightforward reasons).
+3. In the previous case, it was necessary to compute a more precise effective gas price based on the accurate amount of gas, denoted as $\texttt{GasUsedNew}$, obtained during the transaction’s execution using the correct state root at the time of sequencing transactions.
 
     Henceforth, the Executor executes the transaction using $\texttt{EEGP}$, obtaining $\texttt{GasUsedNew}$, which the sequencer utilizes to compute a new effective gas price, referred to as $\texttt{NEGP}$.