# Blob KZG proof verification cost as reserve price in EIP-7918 During the discussion phase for [EIP-7918](https://eips.ethereum.org/EIPS/eip-7918), [Ben Adams](https://x.com/ben_a_adams) has [suggested](https://ethereum-magicians.org/t/eip-7918-blob-base-fee-bounded-by-execution-cost/23271/19) that we compute the minimum blob base fee from the cost of `POINT_EVALUATION_PRECOMPILE_GAS`, as opposed to using `TX_BASE_COST` with amortization across blobs. The design seems worthwhile, and I will here analyze it, based on discussion with—and feedback from—Ben, [Francesco D'Amato](https://x.com/fradamt), [Justin Traglia](https://x.com/JustinTraglia), [Toni Wahrstätter](https://x.com/nero_eth) and [Marius Van Der Wijden](https://x.com/vdwijden). ## Summary The threshold in the `if`-clause is changed by switching constants, but EIP-7918 remains two lines of spec code. The original constants establish a low minimum blob base fee that still ensures a functioning fee market. The suggested 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 simply 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](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/eip-4844#networking) 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. ### EIP-7594 (Fusaka) [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594) introduces PeerDAS and is scheduled for Fusaka. It changes compute requirements due to the reliance on blob cells and their individual proofs. The exact specification is not yet fully settled, but this is a rough guideline: * EL nodes batch-verify `CELLS_PER_EXT_BLOB` (128) cell proofs for each blob before including a tx carrying that blob in their tx pool. This verification (e.g., using `verify_cell_kzg_proof_batch`) is roughly 15 times more expensive than the compute associated with a single `POINT_EVALUATION_PRECOMPILE_GAS` (which is for one `verify_kzg_proof`). * Full nodes must verify 4 custodied columns, each column containing one cell from all blobs referenced in the payload. Each column's cell proofs can be batch-verified. * Supernodes must verify 128 custodied columns, each column containing one cell from all blobs referenced in the payload. Each column's cell proofs can be batch-verified. * Validators between full nodes and supernodes will custody between 4-128 columns. * Nodes peer-sample `SAMPLES_PER_SLOT` (8) columns each slot (in addition to custodied columns). Each column's cell proofs can, as previously, be batch-verified. For the verification performed on the CL in PeerDAS, the ability to jointly process cell proofs of a column (from all blobs) through batching reduces the compute time spent per blob as the number of blobs increases. When columns are batched sequentially, the compute time per blob is still quite high relative to the point evaluation. It is also possible to batch all columns jointly or to parallelize the processing across columns. When accounting for the prospect of parallelization for the CL, it is however worth remembering that the point evaluation proof verification performed by rollups using the precompile should generally not have many dependencies on other transactions in the execution block (both the point evaluation itself and operations taken conditional on the outcome) and thus also lends itself to parallelization. Such parallelization is an important current research focus. This means that a comparison between the point evaluation and the sequential processing of blobs (batched per column) is still relevant (because *both* could be parallelized). Figure 1 shows verification time per blob divided by the measured execution time of a single point evaluation operation (performed by the `VerifyKZGProof` precompile) for various configurations. The test extends [previous tests](https://gist.github.com/jtraglia/698a4f7bd43764db19753f9fa046998e) in the [C-KZG-4844](https://github.com/ethereum/c-kzg-4844/) library by varying the number of blobs in the columns, batching columns jointly, or parallelizing the computations. Associated vibe code and test results are available [here](https://gist.github.com/anderselowsson/b3e67245fa6a32747c157a53a631268f). The cells of a column are always batched by the CL, but the configuration for how to process multiple columns is varied. The computed "point evaluation multiple" falls with a higher blob count on the CL (brown and pink lines) due to benefits from batching. The dashed cyan line shows that this relationship seems to be approximately reciprocal to the logarithm of the targeted number of blobs. The EL mempool verification step for PeerDAS (red), involving cell proof verification, does not benefit from a higher blob count in the worst-case scenario. <!--The EL and CL verification steps are additive: nodes must perform both.--> ![](https://notes.ethereum.org/_uploads/ry4Govwbxg.png) **Figure 1.** Verification time per blob relative to one point evaluation on an Apple M2 Max with 12 cores. The EL mempool verification (red) takes 15 times longer in the worst case, regardless of the blob target. The per-blob verification time of columns depends on the number of custodied/sampled columns and falls with an increase in the blob target due to speed-ups from processing all cells of a column jointly. Processing speeds up when batched or parallelized (albeit with more cores occupied in the latter case). The figure indicates that blobs under the current Fusaka PeerDAS specification will subject nodes to rather heavy compute requirements—when compared to the single point evaluation proof verification that a smart contract is charged `POINT_EVALUATION_PRECOMPILE_GAS` for. A full node would for example do the EL mempool verification for all blobs propagated p2p (already 15x). It would also sample 8 columns which at a target of 32 blobs requires 2x more time when done sequentially (batching each column separately), and they would finally custody 4 designated columns which are about equally as demanding as the point evaluation. As previously discussed, whether or not the parallelized verification is comparable is a nuanced issue. This is true also in general. How to price the KZG proof verification is a complex question given the varying contexts in which it is performed. Charging a minimum price of `POINT_EVALUATION_PRECOMPILE_GAS` could act as a reasonable compromise/lower bound under current circumstances, representing the cost of a basic unit of blob data verification with an assigned gas cost. ## Design To ensure blob transactions compensate for the computational overhead they impose on nodes for verifying their KZG proofs, the protocol would with the suggestion introduce a reserve price per blob benchmarked against `POINT_EVALUATION_PRECOMPILE_GAS`, rebased and charged in blob gas, by applying the following `if`-clause: ```Python if POINT_EVALUATION_PRECOMPILE_GAS * parent.base_fee_per_gas > GAS_PER_BLOB * get_base_fee_per_blob_gas(parent): ``` While the precompile's gas cost is for a distinct contract-level operation, it offers an understandable proxy for a basic unit of blob-related computational work. Accounting for worst-case scenarios imposed by EL verification, there is no amortization across blobs in the calculation. The protocol thus imposes a reserve price on the blob base fee of $$ b_\text{blob} = \frac{50000 \times b_\text{exec.}}{2^{17}}. $$ ## Implications With this change, the protocol would take the position that blob txs have no more right to utilize compute than other txs do, unless they pay their fair share at the prevailing market price (the execution base fee). They must thus pay a blob base fee that at least corresponds to the execution cost of one `POINT_EVALUATION_PRECOMPILE_GAS`, representing a new reserve price. They make the payment via blob gas. The cost for the blob data is still charged on top of this minimum fee, but set fully independently according to the market-clearing price, factoring in the reserve price. From a mechanism design perspective, the EIP would then resolve two separate issues: 1. Ensuring that blob consumers pay at least for the compute they impose, with any further fees for data determined in the independent blob fee market. 2. Ensuring a functioning blob fee update mechanism by establishing a price floor which is significant relative to the minimum execution cost for the blob consumer (this is the previous rationale). By charging the proof verification cost via the blob base fee, (1) and (2) are fulfilled jointly. Any costs imposed in the independent fee market on top of the compute cost are for the actual data. As this base fee is set in blob gas, of which 100% is burned, it is not subject to additional costs via priority fees (the blob consumer can still calibrate priority fees for their blob-carrying tx). Given that `POINT_EVALUATION_PRECOMPILE_GAS > TX_BASE_COST`, there is no need to account for transaction costs for the purpose of establishing a functioning fee market. The solution can be understood as a composite fee market where the cost for a "base" resource (execution) represents the reserve price when charging for the secondary resource (blob data). It should be noted that this change would substantially raise the minimum fee for blobs, relative to the previous proposal. There is no amortization since the cost is imposed for every blob, and `POINT_EVALUATION_PRECOMPILE_GAS = 50000`—thus more than twice as high as `TX_BASE_COST = 21000`. The minimum blob base fee becomes around 38% of the execution base fee: ```python POINT_EVALUATION_PRECOMPILE_GAS / GAS_PER_BLOB = 50000 / 131072 = 0.38 ``` If the execution base fee is 1 gwei, the imposed minimum blob base fee would be 0.38 gwei. If the execution base fee is 2.62 gwei, the imposed minimum blob base fee would be 1 gwei. At a 1 gwei blob base fee and \$2500 ETH price, the protocol would charge at least `131072 * 1 * 2500 / 10**9 = 0.33` dollars for a blob. If the execution base fee is 26.2 gwei, the minimum blob base fee becomes 10 gwei, and the imposed minimum price would be as high as \$3.3 dollars per blob. It is however important to remember that blob consumers would pay for compute that they actually impose on nodes, and that this fee also is imposed on smart contracts via `POINT_EVALUATION_PRECOMPILE_GAS`. It is not an arbitrary fee, but a neutral way to resolve two separate problems with the current fee market design. Furthermore, when compute is in-demand and more expensive, the fee for transacting on the L1 also rises according to the same relative trajectory as the minimum blob base fee. ## Alternative specifications As indicated by the cyan line in Figure 1, the CL's verification cost per blob appears to decrease approximately logarithmically with an increase in the number of processed blobs. If, in the future, the EL's handling of blobs is made more efficient, the minimum blob base fee could be designed to decrease with an increase in blobs according to this subtle amortization schedule. Unfortunately, there is no log-function defined at the EL. A straightforward way to obtain the integer part of a base-2 logarithm (i.e., $\lfloor \log_2 N \rfloor$) is to calculate the bit length of the targeted number of blobs and subtract one. This computation is equivalent to Python's `(target).bit_length() - 1`. The link to the execution base fee ensures that blob consumers pay according to how in-demand compute services of the nodes are at the time that they are requested. But using the constant `POINT_EVALUATION_PRECOMPILE_GAS` directly may be [suboptimal](https://ethereum-magicians.org/t/eip-7918-blob-base-fee-bounded-by-execution-cost/23271/5), even if it currently is deemed appropriate. After all, the `POINT_EVALUATION_PRECOMPILE_GAS` itself might be changed, for example on account of [high proving costs](https://ethresear.ch/t/the-hunt-tracking-organic-prover-killer-blocks-on-ethereum/22332#p-54284-results-3). Furthermore, even if compute costs correspond to `POINT_EVALUATION_PRECOMPILE_GAS`, Ethereum might initially wish to be a "loss-leader" on DA for strategic purposes, and thus charge according to a lower constant. ## Empirical analysis Figures 2-3 show price evolution over three weeks in November 2024, when the average execution base fee was around 16 gwei, as well as in March 2025, when the average was around 1.3 gwei. The observed fee is shown in black and the cost of `POINT_EVALUATION_PRECOMPILE_GAS` in blue, rebased to become the minimum blob base fee as prescribed by the mechanism. EIP-7918 imposes the maximum of the two curves, indicated in darker colors. As evident, the minimum fee becomes rather substantial when execution gas is more expensive, and lower when execution gas is cheaper. ![Figure 2](https://notes.ethereum.org/_uploads/SynGxclZlx.png) **Figure 2.** Blob base fee evolution with the current fee market (black) and the blob-base-fee denominated cost of `POINT_EVALUATION_PRECOMPILE_GAS` (blue), during three weeks of November 2024 when the average execution base fee was around 16 gwei. EIP-7918 imposes the maximum of the two curves, as indicated in darker colors. ![Figure 3](https://notes.ethereum.org/_uploads/ryFAxclZge.png) **Figure 3.** Blob base fee evolution with the current fee market (black) and the blob-base-fee denominated cost of `POINT_EVALUATION_PRECOMPILE_GAS` (blue), during three weeks of March 2025 when the average execution base fee was around 1.3 gwei. EIP-7918 imposes the maximum of the two curves, as indicated in darker colors. Figure 4 shows histograms for observed fees and the maximum of the two curves for the four-month period from November 2024 (start of Figure 2's data period) through March 2025 (end of Figure 3's data period), corresponding to approximately 900k blocks beginning at block number 22075724. The histograms employ 100 log-spaced bins per decade (factor-of-ten increase), which are smoothed using a Hanning window of width 21 with mirror-reflected edges. ![](https://notes.ethereum.org/_uploads/ByFjMSFZlx.png) **Figure 4.** Histogram of the blob base fee when there is no threshold or when applying EIP-7918 with adjusted constants (dashed combination of the darker black and blue curves from previous figures), with light smoothing applied. A four-month period from November 2024 through March 2025 was analyzed. Thresholding is applied directly to the original data, without accounting for its effect on the equilibrium fee.
Last changed by  
 
Anders Elowsson
340

Read more

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
On the EIP-7918 `return` statement

When the if-clause in EIP-7918 evaluates to true, the fee update is operating in the thresholded regime, and should not decrease the blob base fee further. The function then returns: return parent.excess_blob_gas + parent.blob_gas_used // 3 This produces a positive linear response in blob_gas_used that has the same maximum increase as when the if-clause evaluates to false. Two alternatives will be outlined here. Incorporating max blobs in the equation As previously mentioned, computing // 3 ensures that the maximum increase stays the same as in the regular update. Specifically, // 3 compensates for the fact that 1/3 of the max blob gas remains after subtracting TARGET_BLOB_GAS_PER_BLOCK. This is expressed as the equation: (max - target) / max = 1/3. It would be convenient to encode the relationship, which is easily achieved if the EL has access to blobSchedule.target and blobSchedule.max from EIP-7892. In this case, the return statement can be modified to: return parent.excess_blob_gas + parent.blob_gas_used * (blobSchedule.max - blobSchedule.target) // blobSchedule.max If EIP-7892 is confirmed for Fusaka with accessible constants, this return statement could be pursued.

5/20/2025
Untitled

Apples of the Infinite Garden: A Children's Book on EIP-7918 Audrey the Auctioneer, Pontus the Ponderer and Therese the Tree Tender have just started an apple orchard in a huge garden. The friends have a vision: feeding the world with apples. Their orchard currently produces an average of 6 fresh apples every 12 seconds. To set the price, Audrey counts how many apples are sold in each 12-second round and keeps the price fixed if exactly 6 apples are sold. She increases the price by around 10% if more than 6 apples are sold (Pontus sells up to 9 apples when working the fastest he can), and decreases it similarly if none or just a few apples are sold. This is generally a sound approach. The apples are tasty and the friends are sure there will always be demand if the price becomes low enough. The first day, everything runs smoothly and the price rises and falls as expected with changes in apple demand. You hear Audrey announcing "Apples for $16!", and 12 seconds later "Get your apples for $15!", etc. However, the next day a very strange thing happens: when Audrey lowers the price, there is no increase in demand. You hear her calling "Apples for $0.01!", a few hours later, "Apples for $0.0001!", and the next morning "Apples for $0.000000001!". The friends are stunned, they were sure thousands of people would want apples at these giveaway prices. They know they're selling prime apples, and at this price, millions upon millions of apples could be bought for just a dollar. Later that day, demand picks up. Customers swarm the stand, waving money to secure an apple. But Audrey follows the same rule as always, raising the price by 10% per round. It takes seven rounds for the price to increase from $0.000000001 to $0.000000002, and this does not seem to have any effect on demand. Customers try to tip extra to jump the queue, but it's difficult to run the stand that way; things were easier when Audrey had control over apple demand.

4/25/2025
Read more from Anders Elowsson
Published on HackMD