You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/zkEVM/architecture/user-fees.md
+25-22Lines changed: 25 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ The aim with this document is to describe the Effective Gas Price (EGP), a mecha
5
5
6
6
Let's make a quick recollection of the basic fee schema used in Ethereum.
7
7
8
-
Firstly, gas is a unit that accounts for resources used when processing a transaction. At the time of sending a transaction, the user can decide two parameters; $\texttt{gasLimit}$ and $\texttt{gasPrice}$:
8
+
Firstly, gas is a unit that accounts for resources used when processing a transaction. At the time of sending a transaction, the user can decide on two parameters; $\texttt{gasLimit}$ and $\texttt{gasPrice}$:
9
9
10
10
- $\texttt{gasLimit}$ is the maximum amount of gas units that a user is willing to buy in order to complete a transaction.
11
11
@@ -80,15 +80,6 @@ Their corresponding pertinent questions are:
80
80
- How do L2 solutions address and reconcile any discrepancies between the L1 gas schema and the real resource utilization on L2?
81
81
82
82
83
-
### Time-related variations
84
-
85
-
So, how can the fact that the L1 $\texttt{gasPrice}$ varies with time be taken into account?
86
-
87
-
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.
88
-
89
-
90
-
91
-
92
83
## Gas price suggester
93
84
94
85
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.
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
750
753
751
754
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}$.
752
755
753
-
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}$.
756
+
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}$.
754
757
755
758
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.
756
759
@@ -851,15 +854,15 @@ Let’s examine the above figure in more detail.
851
854
852
855
Henceforth, the user is charged the full $\texttt{SignedGasPrice}$, so the Executor will execute the transaction using it, concluding the sequencing process.
853
856
854
-
- Conversely, if $\texttt{SignedGasPrice} > \texttt{EEGP}$, there is a room for further adjustment of the gas price that will be charged to the user.
857
+
- Conversely, if $\texttt{SignedGasPrice} > \texttt{EEGP}$, there's room for further adjustment of the gas price that will be charged to the user.
855
858
856
-
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).
859
+
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.
857
860
858
861
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}$.
859
862
860
-
4. We have to paths:
863
+
4. We have two paths:
861
864
862
-
- If the percentage deviation between $\texttt{EEGP}$ and $\texttt{NEGP}$ is higher than a fixed deviation parameter $\texttt{FinalDeviationPct}$, which is $10$ in the actual configuration, that is
865
+
- If the percentage deviation between $\texttt{EEGP}$ and $\texttt{NEGP}$ is higher than a fixed deviation parameter $\texttt{FinalDeviationParameter}$, which is $10$ in the actual configuration, that is
there is a big difference between executions and we may better adjust gas price due to potential (and quite big) losses to the network or the user.
883
+
there is a big difference between executions and we may want to adjust gas price due to potential losses to the network or the user.
881
884
882
885
5. In the latter case, two options arise:
883
886
884
-
- If the gas price signed is less or equal than the accurate effective gas price computed with the correct state root
887
+
- If the gas price signed is less than or equal to the accurately computed effective gas price, with the correct state root, and
885
888
886
889
$$
887
890
\texttt{SignedGasPrice} \leq \texttt{NEGP}
888
891
$$
889
892
890
-
the network suffers again a risk of loss.
893
+
the network runs the risk of incurring a loss.
891
894
892
-
Henceforth, the user is charged the full $\texttt{SignedGasPrice}$, so the Executor will execute the transaction using it, concluding the sequencing process.
895
+
Hence the user is charged the full $\texttt{SignedGasPrice}$, and the executor therefore executes the transaction using the $\texttt{SignedGasPrice}$. And the sequencing process is concluded.
893
896
894
-
- Otherwise, if $\texttt{SignedGasPrice} > \texttt{NEGP}$, then it means we have margin to adjust the gas price that is charged to the user.
897
+
- Otherwise, if $\texttt{SignedGasPrice} > \texttt{NEGP}$, then there's sufficient margin to adjust the gas price and thus charge the user less than their $\texttt{SignedGasPrice}$.
895
898
896
899
However, in order to save executions, we end the adjustment process in this iteration, so that we conclude the flow using a trick explained in the next point.
897
900
@@ -908,7 +911,7 @@ Let’s examine the above figure in more detail.
908
911
909
912
This precaution is employed to mitigate potential vulnerabilities in deployed Smart Contracts, that arise from creating a specific condition based on the gas price, for example, to manipulate execution costs.
910
913
911
-
- If the transaction does not make use of the gasprice-related opcodes, the Executor executes the transaction with the more adjusted gas price up to this point which is $\texttt{NEGP}$ and end up the sequencing process.
914
+
- If the transaction does not make use of the gas-price-related opcodes, the executor executes the transaction with the more adjusted gas price, which is $\texttt{NEGP}$, and ends the sequencing process.
0 commit comments