Update EIP-4844: Rename gasPrice to baseFee

Merged by EIP-Bot.

EIPS/eip-4844.md

@@ -49,8 +49,8 @@ Compared to full data sharding, this EIP has a reduced cap on the number of thes
 | `POINT_EVALUATION_PRECOMPILE_GAS` | `50000` |
 | `MAX_BLOB_GAS_PER_BLOCK` | `786432` |
 | `TARGET_BLOB_GAS_PER_BLOCK` | `393216` |
-| `MIN_BLOB_GASPRICE` | `1` |
-| `BLOB_GASPRICE_UPDATE_FRACTION` | `3338477` |
+| `MIN_BLOB_BASE_FEE` | `1` |
+| `BLOB_BASE_FEE_UPDATE_FRACTION` | `3338477` |
 | `GAS_PER_BLOB` | `2**17` |
 | `HASH_OPCODE_BYTE` | `Bytes1(0x49)` |
 | `HASH_OPCODE_GAS` | `3` |
@@ -165,20 +165,20 @@ For the first post-fork block, both `parent.blob_gas_used` and `parent.excess_bl
 ### Gas accounting
 
 We introduce blob gas as a new type of gas. It is independent of normal gas and follows its own targeting rule, similar to EIP-1559.
-We use the `excess_blob_gas` header field to store persistent data needed to compute the blob gas price. For now, only blobs are priced in blob gas.
+We use the `excess_blob_gas` header field to store persistent data needed to compute the blob gas base fee. For now, only blobs are priced in blob gas.
 
 ```python
 def calc_data_fee(header: Header, tx: Transaction) -> int:
-    return get_total_blob_gas(tx) * get_blob_gasprice(header)
+    return get_total_blob_gas(tx) * get_blob_base_fee(header)
 
 def get_total_blob_gas(tx: Transaction) -> int:
     return GAS_PER_BLOB * len(tx.blob_versioned_hashes)
 
-def get_blob_gasprice(header: Header) -> int:
+def get_blob_base_fee(header: Header) -> int:
     return fake_exponential(
-        MIN_BLOB_GASPRICE,
+        MIN_BLOB_BASE_FEE,
         header.excess_blob_gas,
-        BLOB_GASPRICE_UPDATE_FRACTION
+        BLOB_BASE_FEE_UPDATE_FRACTION
     )
 ```
 
@@ -275,8 +275,8 @@ def validate_block(block: Block) -> None:
             for h in tx.blob_versioned_hashes:
                 assert h[0] == VERSIONED_HASH_VERSION_KZG
 
-            # ensure that the user was willing to at least pay the current blob gasprice
-            assert tx.max_fee_per_blob_gas >= get_blob_gasprice(block.header)
+            # ensure that the user was willing to at least pay the current blob base fee
+            assert tx.max_fee_per_blob_gas >= get_blob_base_fee(block.header)
 
             # keep track of total blob gas spent in the block
             blob_gas_used += get_total_blob_gas(tx)
@@ -344,7 +344,7 @@ The work that is already done in this EIP includes:
 - _All_ of the execution / consensus cross-verification logic required for full sharding
 - Layer separation between `BeaconBlock` verification and data availability sampling blobs
 - Most of the `BeaconBlock` logic required for full sharding
-- A self-adjusting independent gasprice for blobs
+- A self-adjusting independent base fee for blobs
 
 The work that remains to be done to get to full sharding includes:
 
@@ -353,7 +353,7 @@ The work that remains to be done to get to full sharding includes:
 - PBS (proposer/builder separation), to avoid requiring individual validators to process 32 MB of data in one slot
 - Proof of custody or similar in-protocol requirement for each validator to verify a particular part of the sharded data in each block
 
-This EIP also sets the stage for longer-term protocol cleanups. For example, its (cleaner) gas price update rule could be applied to the primary basefee calculation.
+This EIP also sets the stage for longer-term protocol cleanups. For example, its (cleaner) gas base fee update rule could be applied to the primary basefee calculation.
 
 ### How rollups would function
 
@@ -383,18 +383,18 @@ However, the point evaluation happens inside a finite field, and it is only well
 
 In the interest of not adding another precompile, we return the modulus and the polynomial degree directly from the point evaluation precompile. It can then be used by the caller. It is also "free" in that the caller can just ignore this part of the return value without incurring an extra cost -- systems that remain upgradable for the foreseeable future will likely use this route for now.
 
-### Blob gasprice update rule
+### Blob base fee update rule
 
-The blob gasprice update rule is intended to approximate the formula `blob_gasprice = MIN_BLOB_GASPRICE * e**(excess_blob_gas / BLOB_GASPRICE_UPDATE_FRACTION)`,
+The blob base fee update rule is intended to approximate the formula `blob_base_fee = MIN_BLOB_BASE_FEE * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)`,
 where `excess_blob_gas` is the total "extra" amount of blob gas that the chain has consumed relative to the "targeted" number (`TARGET_BLOB_GAS_PER_BLOCK` per block).
-Like EIP-1559, it's a self-correcting formula: as the excess goes higher, the `blob_gasprice` increases exponentially, reducing usage and eventually forcing the excess back down.
+Like EIP-1559, it's a self-correcting formula: as the excess goes higher, the `blob_base_fee` increases exponentially, reducing usage and eventually forcing the excess back down.
 
 The block-by-block behavior is roughly as follows.
 If block `N` consumes `X` blob gas, then in block `N+1` `excess_blob_gas` increases by `X - TARGET_BLOB_GAS_PER_BLOCK`,
-and so the `blob_gasprice` of block `N+1` increases by a factor of `e**((X - TARGET_BLOB_GAS_PER_BLOCK) / BLOB_GASPRICE_UPDATE_FRACTION)`.
+and so the `blob_base_fee` of block `N+1` increases by a factor of `e**((X - TARGET_BLOB_GAS_PER_BLOCK) / BLOB_BASE_FEE_UPDATE_FRACTION)`.
 Hence, it has a similar effect to the existing EIP-1559, but is more "stable" in the sense that it responds in the same way to the same total usage regardless of how it's distributed.
 
-The parameter `BLOB_GASPRICE_UPDATE_FRACTION` controls the maximum rate of change of the blob gas price. It is chosen to target a maximum change rate of `e(TARGET_BLOB_GAS_PER_BLOCK / BLOB_GASPRICE_UPDATE_FRACTION) ≈ 1.125` per block.
+The parameter `BLOB_BASE_FEE_UPDATE_FRACTION` controls the maximum rate of change of the blob base fee. It is chosen to target a maximum change rate of `e(TARGET_BLOB_GAS_PER_BLOCK / BLOB_BASE_FEE_UPDATE_FRACTION) ≈ 1.125` per block.
 
 ### Throughput
 
@@ -417,7 +417,7 @@ By only broadcasting announcements for blob transactions, receiving nodes will h
 allowing them to throttle throughput to an acceptable level.
 [EIP-5793](./eip-5793.md) will give further fine-grained control to nodes by extending the `NewPooledTransactionHashes` announcement messages to include the transaction type and size.
 
-In addition, we recommend including a 1.1x blob gasprice bump requirement to the mempool transaction replacement rules.
+In addition, we recommend including a 1.1x blob base fee bump requirement to the mempool transaction replacement rules.
 
 ## Test Cases