# EIP-7918 in Fusaka: 3 reasons and 1 trick Tonight, Fusaka goes live and Ethereum updates its blob pricing mechanism with a blob reserve price (a price floor) via [EIP-7918](https://eips.ethereum.org/EIPS/eip-7918). Here are three reasons why EIP-7918 ties the reserve price to the execution price, and the trick that made it all come together on the final submission day. ## Three reasons for tying the reserve price to the execution price ### Reason 1: to retain control over demand Ethereum adapts the gas price with demand. If more blobs are used than the target, the price rises; if fewer, the price falls. Due to this automatic pricing, users do not need to guess how much to pay for inclusion. However, the pricing system only works when the price actually influences demand. If the blob base fee is 1 wei, users hardly notice the fee even if it increases 1,000-fold. Since the blob base fee can at most increase by 12.5% every slot, it may take several hours until it is sufficiently high to produce a target consumption of blobs. During that time, users may want to buy more blobspace than what is available, but it can be hard to know how much to pay (via tips) for it. Where is that inflection point where users begin to care about the blob base fee? Presumably, since users also need to pay for the blob-carrying transaction with execution gas, they only start caring once the cost of the blob gas is some relevant fraction of the execution cost. Therefore, by tying the reserve price to the execution base fee, we can ensure that users always care, at least a little, about the blob base fee. This idea is also explained in a [children's book](https://notes.ethereum.org/@anderselowsson/AIG). ### Reason 2: to use the price of calldata as a reference point In economics, things should often be evaluated on a *relative* basis. If we want to say that the reserve price for blobdata is "too low" or "too high", we need some form of reference point. A good reference point is calldata, which is priced in execution gas. It is preferable not to set the reserve price for blobdata higher than the price for calldata. A fixed reserve price, as was considered in EIP-7762, could have led the reserve price to become either "too low" or "too high" using the calldata reference point. To see the problem, here is what happens with some concrete numbers. At the current base fee of 0.03 gwei, the price per byte of calldata is 16 * 0.03 = 0.48 gwei. That's below the reserve price of 1 gwei per blobdata byte (~2**30 wei) that was suggested in the spring by leading researchers (albeit the EIP-7623 calldata cost floor is 40 * 0.03 = 1.2 gwei, thus slightly higher). The constant actually proposed in EIP-7762 would still be safe, currently pricing calldata 14 times higher than blobdata. But the execution base fee could always fall further, pushing the calldata price below the fixed blob price floor. ![](https://notes.ethereum.org/_uploads/B1YBu_pZbx.jpg) The point I'm trying to make here is that if we want to ensure that blobs have a reserve price that is reasonable relative to the price of calldata or the price of executing the blob-carrying transaction, then the robust approach is to tie the two prices together. In EIP-7918, the reserve price for one byte of blobdata is always 1/256 of the price for one byte of calldata, because it ties the reserve price to the execution price. If calldata is cheaper, some L2s might pivot to calldata, and its equilibrium price could still end up higher than or equal to the blob reserve price. But this pivot would impede the scaling achieved via blobs. If L2s use calldata, they crowd out other users. ### Reason 3: to align the price with the compute costs imposed by blobs Blobs also impose a computational cost on nodes. Nodes must cryptographically verify KZG proofs to ensure that associated commitments correspond to provided blobs. This process is computationally expensive. It seems desirable to ensure that blob consumers pay at least some fraction of the market rate for the compute they impose. The execution base fee reflects how in-demand nodes’ compute services are at the time that blob consumers request them, and is therefore suitable as a reference point for the reserve price. This provides an additional rationale for the design, and was suggested by Ben Adams during the discussion phase for the EIP. ## The trick that made it all come together On the final submission day, it was clear that the design should have a reserve price tied to the execution fee. However, I could not directly enforce it! The issue is that the blob base fee is encoded in `excess_blob_gas` and calculated from it using an exponential function. I wanted to first compute the reserve blob base fee from the execution base fee, and then compute the reserve `excess_blob_gas` from the reserve blob base fee. While the execution layer can easily convert `excess_blob_gas` into a blob base fee, it lacks the "inverse" function to convert a blob base fee into `excess_blob_gas`. Implementing that inverse function would have substantially increased the complexity of the EIP. It was time to think things through and come up with an alternative solution. While the execution layer could not calculate exactly what the `excess_blob_gas` reserve price should be, it could always ask: is the current `excess_blob_gas` too low? You do not need the inverse for that—you only need to determine the blob base fee from the `excess_blob_gas` and compare it with the execution base fee. And this is actually all it takes. If the blob base fee is too low in that comparison, you just let `excess_blob_gas` rise! This is why the EIP has that `if` condition. It was necessary to compare the exponentiation of `excess_blob_gas` with the execution base fee and adjust the response accordingly, because it was not possible to set a specific reserve `excess_blob_gas` from the execution base fee. For reference, here is the final EIP-7918 reserve price logic: ```python if execution_base_fee > 16 * compute_blob_base_fee(excess_blob_gas): # excess_blob_gas rises with every blob consumed else: # excess_blob_gas is updated as normal ```
Last changed by  
 
Anders Elowsson
2313

Read more

Three paradigms for preserving scaling under state creation repricing

What follows is a brief overview of options for preserving scaling under state creation repricing related to EIP-8037. The main concern is that a substantial increase in the state creation gas cost impedes scaling, because more of the available gas is used for state creation in each block. These operations thus crowd out other operations in equilibrium. A deeper analysis is presented by Maria here, and an informal worst-case analysis is available here. There are two orthogonal pathways to preserve scaling. A. Make adjustments to the protocol to allow for higher state growth. B. Make adjustments to how the protocol processes state creation operations. This post focuses on (B). Approaches can be grouped into three paradigms: Repricing – Reprice state creation to shift resource consumption.

12/4/2025
Blob KZG proof verification cost as reserve price in EIP-7918

In the discussion phase for EIP-7918, Ben Adams has suggested that we compute the minimum blob base fee based on the cost of POINT_EVALUATION_PRECOMPILE_GAS, as opposed to using the TX_BASE_COST with amortization across blobs. The design idea seems worthwhile, and I will here analyze it, based on discussion with—and feedback from—Ben, Francesco D'Amato, Justin Traglia, Toni Wahrstätter and Marius Van Der Wijden. Summary There would still be just two lines of code, with the threshold in the if-clause changed by switching constants. The original constants established a low minimum blob base fee that still ensures a functioning fee market. The new constants would raise the minimum blob base fee by charging closer to the workload that blobs impose on nodes, still also ensuring a functioning fee market. The rest of this document just discusses the underlying rationale and implications, illustrating the total workload imposed by blobs on nodes relative to the workload of one point evaluation. Background EIP-4844 (Dencun) EIP-4844 introduced the first phase of Ethereum's data availability sampling (DAS) roadmap. Validators on the consensus layer (CL) verify that the KZG commitments in the payload correspond to the provided blobs by cryptographically verifying the accompanying KZG proofs. Furthermore, execution layer (EL) nodes must also validate the tx_payload_body and verify the wrapped data (blobs, commitments, and proofs) for every blob entering a node's tx pool. MEV-boost also performs similar checks on blobs via the flashbots_validateBuilderSubmission endpoint when they are included in the payload (at least in Nethermind). The computational requirements for verifying a KZG proof for an entire blob are slightly higher than those for verifying a KZG proof for a single point on that blob; the latter is the specific operation covered by the POINT_EVALUATION_PRECOMPILE_GAS (50000) charged to smart contracts. While blobs arriving directly via MEV-boost do not subject EL nodes to the burden of this p2p verification, MEV-boost is an out-of-protocol solution. The protocol should ideally charge users according to the regular (worst-case) scenario of blob txs propagating p2p. This is also the most common behavior today given limited MEV in blobs.

12/2/2025
Dual-deadline PTC vote in ePBS

This is a write-up on an idea first suggested by Mark on Discord here. Key considerations in ePBS are the time allowed for block execution and the time allowed for propagation. Positioning the payload timeliness committee (PTC) vote earlier allows more time for execution and positioning it later allows more time for propagation. A short time for propagation of blobs is particularly unfortunate, given the amount of data that must be propagated before the deadline. However, it turns out that we actually do not need to strictly compromise between either propagation or execution, because the PTC can be instructed to have dual deadlines. The PTC first observes the timeliness of the payload, ensuring it arrives early in the slot, allowing time for more execution. At a later point in the slot, the PTC also checks if the blob data is available (for example in custodied columns, depending on the state of DAS), and casts a positive vote if both deadlines were met. Figure 1 illustrates the design. Note that time indications are tentative and subject to change. Figure 1. A dual-deadline PTC vote in ePBS. The design enforces that the payload is available early in the slot to allow time for execution, but leaves room for blob data to propagate over a longer time. As shown in Figure 1, by staggering the deadlines, the majority of the slot can be used for: execution of the payload, propagation of blobs,

6/27/2025
Considerations for the `BLOB_BASE_COST` in EIP-7918

EIP-7918 introduces the constant BLOB_BASE_COST, constituting the reserve price for a blob expressed in EL gas. The reserve-price design fulfills two separate functions: To ensure a functioning fee market, by keeping the blob base fee in a range where its adjustment affects the demand for blobspace. To charge at least a fraction of the cost for the compute imposed on nodes, at the prevailing market rate. The preliminary setting is: BLOB_BASE_COST = 2**14 # 16384 This means that the blob reserve price is slightly below the cost of a simple tx and that the reserve blob base fee is 1/8 (2**14/2**17) of the execution base fee. The setting balances the two stated goals of the EIP, where (1) is ensured already at a lower setting (e.g., $2^{11}$ or $2^{12}$) and (2) can be satisfied with an even higher setting (e.g., $2^{15}$). During the SFI decision, we left the door open to adjust BLOB_BASE_COST after testing the core functionality in devnets. I will here outline why the preliminary setting was selected and the range of settings that could be considered.

6/19/2025
Read more from Anders Elowsson
Published on HackMD