Skip to content

Commit 55cf1c9

Browse files
EmpieichOEmpieichO
committed
update zkEVM - historical data
2 parents aa8b492 + f24b5a2 commit 55cf1c9

File tree

6 files changed

+379
-6
lines changed

6 files changed

+379
-6
lines changed

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

Lines changed: 179 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -61,16 +61,192 @@ The need for such a factor originates from the fact that the sequencer is oblige
6161

6262
Calculating the breakeven gas price is another measure used in the Polygon zkEVM network to mitigate possible losses.
6363

64-
The breakeven gas price is calculated as a ratio of the total transaction cost and the amount of gas used:
64+
65+
As explained before, the computation is split in two; costs associated with data availability, and costs associated with the use of resources when transactions are processed.
66+
67+
#### Costs associated with data availability
68+
69+
The cost associated with data availability is computed as,
70+
71+
$$
72+
\texttt{DataCost} \cdot \texttt{L1GasPrice}
73+
$$
74+
75+
where $\texttt{DataCost}$ is the cost in gas for data stored in L1.
76+
77+
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.
78+
79+
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:
80+
81+
- The signature, which consists of $65$ bytes.
82+
- The previously defined $\texttt{EffectivePercentageByte}$, which consists of a single byte.
83+
84+
This results in a total of $66$ constantly present bytes.
85+
86+
Taking everything into consideration, $\texttt{DataCost}$ can be computed as:
87+
88+
$$
89+
\texttt{DataCost} = (\texttt{TxConstBytes} + \texttt{TxNonZeroBytes}) \cdot \texttt{NonZeroByteGasCost} \\
90+
+\ \texttt{TxZeroBytes} \cdot \texttt{ZeroByteGasCost}
91+
$$
92+
93+
where $\texttt{TxNonZeroBytes}$ represents the count of non-zero bytes in a raw transaction, and similarly $\texttt{TxZeroBytes}$ represents the count of zero bytes in a raw transaction sent by the user.
94+
95+
#### Computational costs
96+
97+
Costs associated with transaction execution is denoted by $\texttt{ExecutionCost}$, and is measured in gas.
98+
99+
In contrast to costs for data availability, calculating computational costs requires executing transactions.
100+
101+
So then,
102+
103+
$$
104+
\texttt{GasUsed} = \texttt{DataCost} + \texttt{ExecutionCost}
105+
$$
106+
107+
The total fees received by L2 are calculated with the following formula:
108+
109+
$$
110+
\texttt{GasUsed} \cdot \texttt{L2GasPrice}
111+
$$
112+
113+
where $\texttt{L2GasPrice}$ is obtained by multiplying $\texttt{L1GasPrice}$ by a chosen factor less than $1$,
114+
115+
$$
116+
\texttt{L2GasPrice} = \texttt{L1GasPrice} \cdot \texttt{L1GasPriceFactor}
117+
$$
118+
119+
In particular, we choose a factor of $0.04$.
120+
121+
#### Total price of a transaction
122+
123+
The total transaction cost is simply the sum of data availability and computational costs:
124+
125+
$$
126+
\texttt{TotalTxPrice} = \big( \texttt{DataCost} \cdot \texttt{L1GasPrice} \big) + \big(\texttt{GasUsed} \cdot \texttt{L1GasPrice} \cdot \texttt{L1GasPriceFactor} \big)
127+
$$
128+
129+
In order to establish the gas price at which the total transaction cost is covered, we can compute $\texttt{BreakEvenGasPrice}$ as the following ratio:
65130

66131
$$
67132
\texttt{BreakEvenGasPrice} = \frac{\texttt{TotalTxPrice}}{\texttt{GasUsed}}
68133
$$
69134

70-
A marginal profit factor called $\texttt{NetProfit}$ is incorporated in the $\texttt{BreakEvenGasPrice}$ formula as a means of generating a fixed proportion of profit from the total gas fees. It is calculated as follows:
135+
Additionally, we incorporate a factor $\texttt{NetProfit ≥ 1}$ that allows us to achieve a slight profit margin:
71136

72137
$$
73138
\texttt{BreakEvenGasPrice} = \frac{\texttt{TotalTxPrice}}{\texttt{GasUsed}} \cdot \texttt{NetProfit}
74139
$$
75140

76-
The breakeven gas price factor is set to $1.3$​, resulting in a 30% net profit.
141+
We then conclude that it is financially safe to accept the transaction if
142+
143+
$$
144+
\texttt{SignedGasPrice} > \texttt{BreakEvenGasPrice}.
145+
$$
146+
147+
However, a problem arises:
148+
149+
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.
150+
151+
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.
152+
153+
This ensures that the costs are covered in case more gas is ultimately required to execute the transaction. This factor is named $\texttt{BreakEvenFactor}$.
154+
155+
Now we can conclude that if
156+
157+
$$
158+
\texttt{SignedGasPrice} > \texttt{BreakEvenGasPrice} \cdot \texttt{BreakEvenFactor}
159+
$$
160+
161+
then it is safe to accept the transaction.
162+
163+
Observe that we still need to introduce gas price prioritization, which we explain later.
164+
165+
### Example (Breakeven gas price)
166+
167+
Recall the example proposed before, where the $\texttt{GasPriceSuggested}$ provided by RPC was $2.85$ gwei per gas, but the user ended up setting $\texttt{SignedGasPrice}$ to $3.3$.
168+
169+
The figure below depicts the current situation.
170+
171+
![Figure: Timeline current L1GasPrice](../../../img/zkEVM/timeline-current-l1gasprice.png)
172+
173+
Suppose the user sends a transaction that has $200$ non-zero bytes, including the constants and $100$ zero bytes.
174+
175+
Moreover, on pre-executing the transaction without an out-of-counters (OOC) error, $60,000$ gas units are consumed.
176+
177+
Recall that, since we are using a "wrong" state root, this amount is only an estimation.
178+
179+
Hence, using the previously explained formulas, the total transaction cost is:
180+
181+
$$
182+
\begin{aligned}
183+
&\texttt{TotalTxPrice} = \texttt{DataCost} \cdot \texttt{L1GasPrice} + \texttt{GasUsed} \cdot \texttt{L1GasPrice} \cdot \texttt{L1GasPriceFactor}\\
184+
&\implies \texttt{TotalTxPrice} = (200 · 16 + 100 · 4) · 21 + 60, 000 · 21 · 0.04 = 126, 000\ \texttt{GWei}
185+
\end{aligned}
186+
$$
187+
188+
Observe that the $21$ appearing in the substitution is the $\texttt{L1GasPrice}$ at the time of sending the transaction.
189+
190+
Now, we are able to compute the $\texttt{BreakEvenGasPrice}$ as:
191+
192+
$$
193+
\texttt{BreakEvenGasPrice} = \frac{\texttt{TotalTxPrice}}{\texttt{GasUsed}} = \frac{126,000\ \texttt{GWei}}{60,000\ \texttt{Gas}} \cdot 1, 2 = 2.52\ \texttt{ GWei/Gas}
194+
$$
195+
196+
We have introduced a $\texttt{NetProfit}$ value of $1.2$, indicating a target of a $20\%$ gain in this process.
197+
198+
At first glance, we might conclude the transaction has been accepted:
199+
200+
$$
201+
\texttt{SignedGasPrice} = 3.3 > 2.52
202+
$$
203+
204+
but, recall that this is only an estimation, the gas consumed with the correct state root can differ.
205+
206+
To avoid this, we introduce a $\texttt{BreakEvenFactor}$ of $30\%$ to account for estimation uncertainties:
207+
208+
$$
209+
\texttt{SignedGasPrice} = 3.3 > 3.276 = 2.52 · 1.3 = \texttt{BreakEvenGasPrice} \cdot \texttt{BreakEvenFactor}
210+
$$
211+
212+
Consequently, the system accepts the transaction.
213+
214+
### Example (Breakeven factor)
215+
216+
Suppose we disable the $\texttt{BreakEvenFactor}$ by setting it to $1$.
217+
218+
Our original transaction’s pre-execution consumed $60,000$ gas:
219+
220+
$$
221+
\texttt{GasUsedRPC} = 60, 000
222+
$$
223+
224+
However, let's assume the correct execution at the time of sequencing consumes $35,000$ gas.
225+
226+
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.
227+
228+
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}$.
229+
230+
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.
231+
232+
In the worst case we are losing:
233+
234+
$$
235+
105, 000 − 35, 000 · 2.85 = 5,250\ \texttt{GWei}
236+
$$
237+
238+
By introducing $\texttt{BreakEvenFactor}$, we are limiting the accepted transactions to the ones with,
239+
240+
$$
241+
\texttt{SignedGasPrice} ≥ 3.27
242+
$$
243+
244+
in order to compensate for such losses.
245+
246+
In this case, we have the flexibility to avoid losses and adjust both the user's and Polygon zkEVM network's benefits since:
247+
248+
$$
249+
105, 000 − 35, 000 · 3.27 < 0
250+
$$
251+
252+
**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‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ Now that the EGP is in place, you can reduce any chance for a transaction revert
66

77
## How gas fees work in Ethereum
88

9-
In Ethereum, gas fees for a transaction are decided using two adjustable parameters:
9+
In Ethereum, there are two adjustable parameters that have a direct impact on transaction gas fees:
1010

1111
- 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.
1212
- 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‎

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -55,3 +55,73 @@ $$
5555
The RPC flow is summarized in the figure below.
5656

5757
![Figure: RPC flow](../../../../img/zkEVM/gas-price-flows-i.png)
58+
59+
60+
## Example (RPC tx flow)
61+
62+
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.
63+
64+
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.
65+
66+
![Figure: Suggested gas price (first)](../../../../img/zkEVM/timeline-current-l1gasprice-suggstd.png)
67+
68+
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$.
69+
70+
The RPC node responds with a $2.85 \texttt{ GWei/Gas}$, as the value of the suggested L2 gas price.
71+
72+
This value is obtained as follows:
73+
74+
$$
75+
\texttt{GasPriceSuggested} = 0.15 \cdot 19 = 2.85 \texttt{ GWei/Gas}
76+
$$
77+
78+
where $0.15$ is the zkEVM's suggested factor.
79+
80+
2. Let's suppose the user sends a transaction signed with a gas price of $3$. That is, $\texttt{SignedGasPrice} = 3$.
81+
82+
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}$.
83+
84+
Note that the minimum suggested L2 gas price, in the 5-min time interval, is $2.85$. And since
85+
86+
$$
87+
\texttt{SignedGasPrice} = 3 > 2.85 = \texttt{L2MinGasPrice}
88+
$$
89+
90+
the transaction gets accepted for pre-execution.
91+
92+
3. At this point, the RPC makes a request for pre-execution. That is, getting an estimation for the gas used, computed with a state root that differs from the one used when the transaction is sequenced.
93+
94+
In this case, suppose an estimation of gas used is $\texttt{GasUsedRPC} = 60,000$, without an out of counters (OOC) error.
95+
96+
4. Since there's no out of counters (OOC) error, the next step is to compute the $\texttt{BreakEvenGasPriceRPC}$.
97+
98+
Suppose it works out to be:
99+
100+
$$
101+
\texttt{BreakEvenGasPriceRPC} = 2.52\ \texttt{GWei/Gas}
102+
$$
103+
104+
(Details on how this calculation are covered later in the [Implementing EGP strategy section](../implement-egp-strat.md).)
105+
106+
5. As noted in the outline of the RPC transaction flow, one more check needs to be done. That is, testing whether:
107+
108+
$$
109+
\texttt{SignedGasPrice} > \texttt{BreakEvenGasPriceRPC} \cdot \texttt{BreakEvenFactor}
110+
$$
111+
112+
Using the $\texttt{BreakEvenFactor} = 1.3$ yields:
113+
114+
$$
115+
\texttt{BreakEvenGasPrice} \cdot \texttt{BreakEvenFactor} = 2.52 \cdot 1.3 = 3.276
116+
$$
117+
118+
And since $\texttt{SignedGasPrice} = 3 < 3.276$, the transaction is not immediately stored in the transaction pool.
119+
120+
6. However, since
121+
122+
$$
123+
\texttt{SignedGasPrice} = 3 ≥ 2.85 = \texttt{GasPriceSuggested}
124+
$$
125+
126+
and despite the risk of the network sponsoring the transaction, it is included in the transaction pool.
127+

0 commit comments

Comments
 (0)