Update EIP-7999: Minor edits to EIP-7999

Merged by EIP-Bot.

Author: anderselowsson

EIPS/eip-7999.md

@@ -145,15 +145,15 @@ def get_required_max_fee(base_fees: list[int], tx_gas_limits: list[int]) -> int:
     return sum(vector_mul(base_fees, tx_gas_limits))
 ```
 
-**At the start of block processing**:
+**At the start of processing a block**:
 
-  * We initialize a vector `gas_used_so_far` to `[0, 0, 0]`.
+  * initialize a vector `gas_used_so_far` to `[0, 0, 0]`,
+  * derive the base fee `base_fees = get_block_base_fees(block.parent)`.
 
 **At the start of processing a transaction**:
 
   * Derive basic properties of the tx: 
     * `max_fee = get_max_fee(tx)`, 
-    * `base_fees = get_block_base_fees(block.parent)`,
     * `tx_gas_limits = get_gas_limits(tx)`.
     * `max_base = get_required_max_fee(base_fees, tx_gas_limits)`
   * Require that 
@@ -275,33 +275,23 @@ Besides UX, resource-specific fee limits can also be unfortunate at a deeper eco
 
 Consider a multidimensional transaction with a `gas_limit` vector $\mathbf{l} = (l_1, l_2,\dots, l_n)$, a `max_fee_per_gas` vector $\mathbf{f} = (f_1, f_2, \dots, f_n)$, and a `max_priority_fee_per_gas` vector $\mathbf{p} = (p_1, p_2, \dots, p_n)$. The consumed gas of the transaction is denoted $\mathbf{g} = (g_1, g_2, \dots, g_n)$, and the vector of base fees is denoted $\mathbf{b} = (b_1, b_2, \dots, b_n)$. The realized priority fee, after ensuring a sufficient base fee, is then
 
-$$
-p{\prime}_i = \min(p_i, f_i-b_i)
-$$
+$p{\prime}_i = \min(p_i, f_i-b_i)$
 
 for all resources $i$. Assume that when the transaction is submitted, the user specifies a `max_fee_per_gas` vector $\mathbf{f}$ such that all entries individually satisfy all base fee $\mathbf{b}$  criteria
 
-$$
-f_i \ge b_i \quad \text{for all resources } i.
-$$
+$f_i \ge b_i \quad \text{for all resources } i.$
 
 The gas limits also satisfy the actual gas consumption
 
-$$
-l_i \ge g_i \quad \text{for all resources } i.
-$$
+$l_i \ge g_i \quad \text{for all resources } i.$
 
 The `max_priority_fee_per_gas` vector $\mathbf{p}$ is also considered sufficient by many proposers, when they jointly weigh the reward against competing transactions using a weight vector $\mathbf{w}$, considering contention across relevant resources:
 
-$$
-\sum p{\prime}_i g_i \ge \sum w_i g_i.
-$$
+$\sum p{\prime}_i g_i \ge \sum w_i g_i.$
 
 While not evaluated in the existing EIP, the base fees $\mathbf{b}$ could also be satisfied in aggregate against the max fees:
 
-$$
-\sum f_i l_i \ge \sum b_i l_i.
-$$
+$\sum f_i l_i \ge \sum b_i l_i.$
 
 Now assume that the base fee for any of the resources rapidly rises before the transaction is included, such that it becomes higher than the `max_fee_per_gas` in that dimension. In this scenario, the transaction can no longer be included. This may happen, even though the *aggregate* fees that the user is offering to pay, $\sum f_i l_i$, remain at a level above the aggregate fees that the protocol demands to execute it, $\sum b_i l_i$, just as initially. The aggregate priority fees may still also satisfy the proposer. The welfare loss consists of a user, a proposer, and a protocol willing to process a transaction, hamstrung by rigidity in the protocol design.