Merge pull request 0xPolygon#270 from 0xPolygon/edit-user-fees

Update zkEVM docs - Edit "User fees" doc

Author: EmpieichO

docs/zkEVM/architecture/user-fees.md

@@ -1,7 +1,6 @@
 The aim with this document is to describe the Effective Gas Price (EGP), a mechanism by which the Polygon zkEVM network charges gas fees in a more fair and accurate manner. These fees cover L1 data-availability and L2 execution costs. It is meant to help users set the $\texttt{gasPrice}$ such that there's little chance for a transaction revert or failure.
 
 
-
 ## Basic Ethereum fee schema
 
 Let's make a quick recollection of the basic fee schema used in Ethereum.
@@ -38,8 +37,7 @@ $$
 \texttt{initialBalance} − \texttt{gasLimit} \cdot \texttt{gasPrice}
 $$
 
-where $\texttt{initialBalance}$ represents the balance of the source account before the execution of the transaction. 
-
+where $\texttt{initialBalance}$ represents the balance of the source account before the execution of the transaction.
 
 
 ## Generic gas fee strategy for L2s
@@ -82,19 +80,15 @@ 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.
@@ -107,12 +101,9 @@ Pre-execution of a transaction involves the following stages:
 
 See the the picture below for an overview of the pre-execution process.
 
-
-
 ![Figure: RPC tx pre-execution](../../img/zkEVM/rpc-tx-preexec.png)
 
 
-
 ### Naïve approach
 
 Let's look at this in two parts; gasPrice suggestion, and transaction sending.
@@ -426,7 +417,18 @@ where $\texttt{TxNonZeroBytes}$ represents the count of non-zero bytes in a raw
 
 ### Computational costs
 
-Computational cost is calculated with the following formula:
+
+Costs associated with transaction execution is denoted by $\texttt{ExecutionCost}$, and it is measured in gas.
+
+In contrast to costs for data availability, calculating computational costs necessecitates transactions to be executed.
+
+So then,
+
+$$
+\texttt{GasUsed} = \texttt{DataCost} + \texttt{ExecutionCost}
+$$
+
+The total fees received by L2 are calculated with the following formula:
 
 $$
 \texttt{GasUsed} \cdot \texttt{L2GasPrice}
@@ -440,7 +442,7 @@ $$
 
 In particular, we choose a factor of $0.04$.
 
-In contrast to costs for data availability, calculating computational costs necessecitates transactions to be executed.
+
 
 
 
@@ -838,11 +840,7 @@ Let’s examine the above figure in more detail.
     Recall that the $\texttt{GasUsedRPC}$ is obtained in the RPC pre-execution using;
 
     - A previous state root, which has now changed, and 
-    - The current $\texttt{L1GasPrice}$, which may also differ from the one used when sending the transaction to the RPC, for all the transactions stored in the Pool, and sequence the one having higher $\texttt{EEGP}$.
-
-    It is important to note that this should be done in this precise order.
-
-    We could have calculated the $\texttt{EEGP}$ just before storing the transactions in the Pool and sorting it by EEGP, but this would not yield the same result because the $\texttt{L1GasPrice}$ at that moment is different from the one at the time of sequencing a transaction, potentially changing the $\texttt{EEGP}$ as well as the prioritization order of transactions.
+    - The current $\texttt{L1GasPrice}$, which may also differ from the one used when sending the transaction to the RPC.
 
 2. At this point, we have two options: